Протоколы для передачи мультимедийных потоков

К передаче мультимедийных потоков предъявляются особые требования, которые не могут быть удовлетворены HTTP. В этом разделе мы обсудим протоколы, которые способны удовлетворить требованиям, относящимся к следующим категориям.

•          Передача данных. Потоковое мультимедиа требует доставки данных с теми же временными характеристиками одному или нескольким получателям. Транспортировка потока обслуживается двумя тесно взаимосвязанными протоколами. Протокол Real-time Transport Protocol (RTP) делит поток на пакеты, каждый из которых содержит отметку времени, порядковый помер и информацию об отправителе [SCFJ96]. Спецификация RTP также определяет протокол RTP Control Protocol (RTCP), по которому осуществляется обрат- пая связь с информацией о качестве передачи и идентификационных данных участников потока.

•          Создание сеанса. Потоковое мультимедиа требует, чтобы отправители и получатели могли выражать свою заинтересованность в участии в мультимедийном сеансе. Соответствующий протокол зависит от копкретпого применения. Протокол Session Initiation Protocol (SIP) используется для приглашения пользователя присоединиться к сеапсу [SSR99j. Протокол Session Announcement Protocol (SAP) используется для объявления Группы вещапия, к которой клиенты могут присоединиться [HPW00j. Протокол Real Time Streaming Protocol (RTSP) позволяет клиенту отправлять сообщение-запрос мультимедийному серверу [SRL98J.

•          Описание сеанса. Участникам сеаиса пужпо получить метаданные, такие как параметры передачи и кодирования составляющих потоков, продолжитель- иость, название и назначение сеанса. Эта информация передается с помощью протокола Session Description Protocol (SDP) [HJ98J.

• Описание представления. Создапие мультимедийных документов требует эффективного способа для организации воспроизведения сеансов во времени. Являясь альтернативой HTML, язык Synchronized Multimedia Integration Language (SMIL) предоставляет возможность управлять, когда, где и как будут воспроизводиться мультимедийные сеапсы [Syn98, Hos00, SmiJ.

RTP, RTCP, SIP, SAP, RTSP и SDP специфицированы в документах запросов на комментарии (Request for Comments), разработанных Internet Engineering Task Force (IETF). За спецификацию SMIL отвечает World Wide Web Consortium (W3C).

Передача данных

RTP и RTCP коордипируюг доставку мультимедийного потока одному или нескольким получателям. RTP [SCFJ96, Tho96J удовлетворяет основным требованиям по транспортировке мультимедийных потоков для разнообразных приложений, таких как мультимедиа по запросу, IP-телефопия и телеконференции. Данные в RTP-иакете ассоциируются с определенным звуковым сэмплом или видеокадром в потоке; один сэмпл или кадр может размещаться в нескольких RTP-пакетах. Заголовок RTP помогает получателю интерпретировать данные.

Таймирование. Получатель должен иметь информацию для координации вос- ироизведепия потока. Промежутки между кадрами могут быть определены из RTP-заголовков без необходимости синхронизации часов отправителя и получателя. RTP-заголовок содержит 32-битное поле времеипой метки относительно момента времени, когда был воснроизведеп первый сэмпл. Все пакеты звукового сэмпла или видеокадра имеют одно и то же значение временной метки. Первый RTP-пакет в потоке имеет случайную отметку времени, подобно случайному начальному порядковому номеру нервого накета в TCP. Временные метки способствуют корректному воспроизведеиию последовательности сэмплов или кадров в потоке. Эго дает возможность получателю воспроизводить данные с соответствующими интервалами времени между последовательными сэмплами или кадрами.

Упорядочение. В RTP отсутствует механизм надежной доставки и управления информационным потоком. Доставка RTP-пакетов зависит от транспортного протокола. RTP не предполагает, что транспортный протокол обеспечивает упорядоченный, надежный байтовый поток, поскольку повторная передача потерянных пакетов для многих мультимедийных потоков нежелательна. В действительности RTP обычно работает поверх UDP, а каждый RTP-пакет передается в одном UDP-пакете. Альтернативой является использование ТСР для обеспечения падежного транспорта либо передачи потока через межсетевой экран, который отвергает UDP-пакеты. Однако IP-пакеты могут быть потеряны или поступать не в гом порядке, а UDP не осуществляет какой-либо повторпой передачи или упорядочения пакетов. RTP-заголовок содержит порядковый помер, дающий возможность получателю обрабатывать поступающие пакеты в нужном порядке и обнаруживать потери пакетов. Получатель может вести статистику потерь пакетов для обратной связи с отправителем. Данные такой статистики могут заставить отправителя скорректировать скорость передачи данных.

Идентификация источника. Помимо информации для таймирования и упорядочения, RTP-заголовок идентифицирует источник (источники), ответственные за данные в пакете. Это особенно полезно для приложений, которые могут иметь несколько источников данных (например, телеконференции). Каждый источпик идентифицируется 32-битным числом. Каждый RTP-пакет имеет синхронизирующий источник, ответственный за временную метку и порядковый номер данных. В некоторых ситуациях синхронизирующий источник генерирует данные с иомо- щыо одного или нескольких дополнительных источников. Рассмотрим приложение для организации телеконференций с несколькими участниками. Каждый участник генерирует аудиопоток и направляет RTP-пакеты промежуточной системе — микшеру. Микшер объединяет пакеты участников и генерирует один аудиопоток. Микшер является синхронизирующим источником для иового потока. Изначальные участники являются участвующими источниками. При объединении отдельных аудиопотоков микшер формирует список участвующих источников для синхронизации составляющих нотоков. Включая идентификаторы участвующих исгочииков в RTP-заголовок, микшер информирует получателей обо всех сторопах, ответственных за объединенный поток.

Формат представления. Интерпретация данных RTP на стороне получателя зависит от выбранного формата кодирования. RTP-заголовок содержит 7-битиое иоле типа полезной нагрузки, идентифицирующее формат мультимедийных данных. Тип полезной нагрузки ассоциируется с именем и описанием кодировки, включая частоту временных меток. Формат нолезпой нагрузки определяет синтаксис и семантику данных RTP, в том числе специфичных для содержимого заголовков. Первый набор типов полезной нагрузки был определен в документе RFC 1890 [Sch96J. Новые типы кодировок регистрируются организацией Internet Assigned Numbers Authority (IANA). Подробные описания типов нолезпой нагрузки, содержащиеся в соответствующих документах, таких как RFC, позволяют разработчикам осуществлять поддержку схем кодирования. Типы полезной нагрузки были также определены для общеунотребительпых мультимедийных сервисов, включая RTP-микшеры и избыточное кодирование аудиоинформации, устойчивое к потерям пакетов. Для достижения гибкости и расширяемости RTP также поддерживает использование динамических типов полезной нагрузки, которые не были зарегистрированы IANA.

Хотя RTP предоставляет большую часть информации, необходимой для передачи мультимедийных данных от отправителя одному или нескольким получателям, иногда требуется некоторая дополнительная управляющая информация. Определенный в том же RFC, что и RTP [SCFJ96], RTCP выполняет следующие три функции:

•          Обратная связь. RTCP предоставляет обратную связь о качестве приема, например, статистику потерь RTP-пакетов получателем. Это помогает RTP-or- правителю выявлять проблемы с производительностью и соответствующим образом адаптировать скорость передачи дапных.

•          Идентификация. RTCP связывает каждый идентификатор источника из RTP-пакетов с уникальным каноническим именем. Это дает возможность получателю ассоциировать набор потоков, возможно, имеющих различные 32-бит- ные идентификаторы источников, с одним отправителем.

•          Синхронизация. RTCP связывает реалы-юе время с временными метками в RTP-пакетах. Это позволяет получателю синхронизировать воспроизведение нескольких потоков, включая аудио и видео, принадлежащих одному сеансу.

Создание сеанса

Отправители и получатели должны иметь способ выразить свою заиитересовап- пость в участии в определенном мультимедийном сеансе. Детали установления соединения между двумя или более сторопами варьируются в зависимости от типа приложения, как говорилось рапее в разделе 12.1.3. Это получило воплощение в нескольких различных протоколах:

•          Session Initiation Protocol (SIP). SIP [SSR99, SR99J поддерживает приложения, такие как IP-телефопия, в которых принимающая сторона получает персональное приглашение для участия в сеансе. Сторона, инициирующая сеапс, может использовать SIP для нахождения одного или более пользователей и пригласить их принять участие в сеансе. SIP выполняет пягь основных функций: (1) решает, с каким компьютером установить контакт, (2) определяет, какие параметры использовать, (3) определяет, желает ли пользователь принять вызов, (4) устанавливает соединение с пользователем, (5) обслуживает передачу и завершает вызов.

•          Session Announcement Protocol (SAP). SAP [HPW00] поддерживает такие приложения, как Internet-радио, в которых предполагаемые участники заранее не известны. Вместо того чтобы организовывать обращение к получателям на стороне отправителя, заинтересованные пользователи посылают запрос на вступление в группу вещания, связанную с сеансом. Однако пользователь может не знать, какая группа вещания соответствует данному мультимедийному сеансу. SAP периодически отправляет анонсирующий пакет, содержащий описание сеанса, на известный адрес груннового вещания и помер порта (9875). Это можно сравнить с телевизионной станцией, которая сообщает о программе передач средствам массовой информации. SAP-слушатель получает анонс, присоединяясь к известной группе вещания. SAP-слушагели могут сами распространять информацию о сеансе среди других пользователей.

•          Real Time Streaming Protocol (RTSP). RTSP дает возможность пользователям извлекать мультимедийное содержание rio запросу, выдавая запрос мультимедийному серверу, подобно отправке HTTP-запроса на Web-сервер. Мультимедийные сеансы и составляющие их потоки идентифицируются URL. Клиент выдает RTSP-запросы для получения информации о сервере и мультимедийном сеансе, а также для воспроизведепия, паузы, записи или просмотра потоков. RTSP предоставляет абстракцию «дистанционного сетевого управления» мультимедийным сервером. RTSP обычно не доставляет данные. Оп используется для выбора транспортного механизма (например, RTP и RTCP), транспортного протокола (например, индивидуальное вещание по UDP, грунновое вещание по UDP или TCP) и определенных номеров нортов (например, портов 6970 и 6971). Спецификация RTSP во многом основана на синтаксисе и семантике НТТР/1.1, о чем подробнее рассказывается в разделе 12.4.

Описание сеанса

Вне зависимости от того, как был создан мультимедийный сеапс. участникам нужно получить огшсапие сеанса. Например, участникам нужпо зпать имя и назначение сеанса, параметры представления составляющих его потоков аудио и видео, IP-адреса и номера портов. Эта информация передается в стандартном формате, определяемом SDP (Session Description Protocol) [HJ98]. В действительности SDP — это не протокол, а язык или формат доставки информации о сеансе. Ониса- пия сеаисов передаются другими протоколами, иапример, SIP, SAP, RTSP и HTTP. Например, HTML-файл может иметь гипертекстовую ссылку, которая указывает на SDP-файл. С точки зрения пользователя щелчок мышью на гипертекстовой ссылке инициирует передачу данных  аудио или видео. В реальности же Web-6pay- зер посылает HTTP-запрос Web-cepвepy для извлечения описания сеанса, а затем активизирует медиаплейер для обработки сообщения HTTP-ответа (например, SDP-файла). После этого медиаплейер осуществляет синтаксический разбор SDP- файла и связывается с одним или с несколькими мультимедийными серверами для извлечения аудио- и видеопотоков.

Описание SDP состоит из одной или нескольких строк текста в формате ASCII. Каждая строка включает состоящий из одного символа тип и значение в виде текстовой строки, разделенные знаком равенства. Формат строки значения зависит от типа. Описание содержит одну или несколько строк с информацией сеансового уровня, за которой может следовать дополнительная информация об отдельных потоках в сеансе. Информация сеансового уровня применяется ко всему сеансу и к каждому из мультимедийных потоков. Информация сеансового уровня включает имя и назначение сеанса в виде текстовых строк, например

s=Web Seminar

i=What everyone needs to know about the World Wide Web

Раздел сеансового уровня может также содержать имя, адрес электронной почты и помер телефона лица, ответственного за сеапс, а также URL с дополнительной информацией. Кроме того, раздел сеансового уровня может содержать информацию о ключах шифрования, необходимых для участия в мультимедийном сеансе или для получения индивидуальных потоков. Описание также включает время начала и время окончания сеаиса в формате Network Time Protocol (NTP) [Mil92J и необязательные указания по требованиям к пропускной способности.

Описание SDP также содержит информацию о каждом мультимедийном потоке, такую как тип содержания и формат кодирования (например, видео в формате MPEG). Кроме этого, SDP сообщает информацию по доставке потока: трапснорт- ный протокол (например, UDP) и разбивка на кадры (например, RTP). Для потока груннового вещапия описание сеанса включает IP-адрес и помер порта груннового вещания. Получатель использует эту информацию для вступления в соответствующую группу вещапия. Для потока индивидуального вещапия описание сеанса содержит доменное имя или IP-адрес источника данных. Получатель может выдать DNS-запрос для преобразования доменного имени в IP-адрес, а затем связаться с удалепным Компьютером для установления коммуникационного взаимодействия. Описание может также указывать на требования потока к пропускпой способности сети. Получатель может использовать параметр пропускпой способности для того, чтобы определить, принимать ли поток.

Описание презентаций

Создание мультимедийного содержимого требует наличия стандартного способа для подготовки презентаций. Язык гипертекстовой разметки Hypertext Markup Language (HTML) служит этой цели применительно к традиционному Web-содержанию. Однако HTML не имеет составляющих для управления временными свойствами мультимедийных презентаций. Разработанный W3C стандарт SMIL представляет собой язык разметки для построения ногоковых мультимедийных презентаций с привязкой по времени, где объедены аудио-, видеоданные, текст и изображения [Syn98, Hos00, SmiJ. SMIL позволяет разработчикам задавать, какое содержание отображать (и где оно находится), где содержание следует отобразить на экране и когда содержание должно быть отображено. Подобно HTML, SMIL дает возможность авторам встраивать гипертекстовые ссылки, по которым осуществляются переходы, когда пользователь щелкает мышью на соответствующей чувствительной области на экране.

Автор SMIL-файла может определять разметку в виде набора областей. Каждая область представляет собой прямоугольник с определенными размерами в определенном месте на экрана. Каждая область ассоциируется с мультимедийными данными. Рассмотрим пример, когда университетский профессор читает лекцию удаленной аудитории. Презентация может связывать различные области с видеоизображением преподавателя, картинкой текущего слайда, демонстрируемого аудитории, и видеоизображением аудитории. Каждое из трех представлений занимает определенную часть экрана и может быть извлечено из различиых источников с помощью различных протоколов и форматов кодирования. SMIL поддерживает встроенные гипертекстовые ссылки, например, щелчок на области с изображением в презентации может инициировать HTTP-запрос на Web-страницу, которая отображает подробную информацию по теме, освещаемой текущим слайдом. В более общем случае гипертекстовая ссылка может ассоциироваться с определенной областью и интервалом времени.

Помимо связывания отображения содержания с областями экрана, SMIL дает возможность автору координировать отображение данных во времени. В SMIL имеются возможности для указания, когда начинать воспроизведение потока и какую часть потока воспроизводить. SMIL содержит средства для синхронизации различных потоков или сеансов. Отдельные сеапсы могут воспроизводиться последовательно, когда воспроизведение одного потока начинается после завершения воснроизведения предыдущего потока. Альтернативой является одновременное воспроизведение нескольких потоков. Плейер определяет, все ли параллельные потоки были завершены, когда можно воспроизводить следующий поток в последовательности. Параллельный и последовательный подходы могут быть объединены, чтобы дать возможность воспроизвести один длинный ноток параллелыю с последовательностью более коротких потоков.

Подготовка мультимедийного содержания осложняется тем фактом, что клиенты могут сильно различаться по пропускной способности, размеру экрана, возможностям плейера и предпочтениям пользователя. Например, один пользователь может иметь 21-дюймовый монитор с высоким разрешением и высокопроизводительное подключение к Internet. Другой пользователь может иметь карманный Компьютер с беспроводным подключением. Слабослышащий пользователь может предпочесть получать текстовое сопровождение вместо потока аудиоинформации. SMIL может задавать различные параметры презентации, соответствующие различным мультимедийным потокам. Медиаплейер определяет, какие потоки извлекать и как их следует отображать. Это является удобной альтернативой обращения клиента к серверу с целью определить соответствующие параметры для потоков. SMIL может также задавать множество параметров презентации для определенной области, которые указывают, как пользователь может взаимодействовать с презентацией. Например, область может поддерживать увеличение и уменьшение изображения.

Источник: Web-протоколы. Теория и практика. — M.: ЗАО «Издательство БИНОМ», 2002 г. – 592 c.: ил.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100