Чтобы начинать и останавливать поток медиа, проигрыватель должен осуществлять удаленное управление сервером. Оно обеспечивается протоколом RTSP, предоставляющим соответствующий механизм управления. Он определен в RFC 2326. Кроме начала и остановки воспроизведения, файл может прокручиваться назад и вперед до определенной позиции, могут проигрываться определенные части, а также использоваться ускоренное или замедленное проигрывание. Однако этот стандарт не определяет поток данных, хотя обычно это RTP через UDP или RTP через HTTP через TCP. Основные команды RTSP приведены в табл. 7.16. Они представлены в простом текстовом формате, как HTTP-сообщения, и обычно передаются при помощи TCP. RTCP может также работать через UDP, так как каждая команда подтверждается (и может быть повторно отправлена, если она не подтверждена).

Несмотря на то что кажется, что TCP плохо подходит для трафика в реальном времени, он часто используется на практике. Основная причина заключается в том, что он проще проходит через межсетевые экраны, чем UDP, особенно если он запускается через HTTP-порт.

Таблица 7.16. Команды RTSP, посылаемые проигрывателем на сервер

Команда

Действие сервера

DESCRIBE

SETUP

PLAY

RECORD

PAUSE

TEARDOWN

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

Устанавливает логическое соединение между проигрывателем и сервером

Начинает отправлять данные клиенту

Начинает прием данных от клиента

Приостанавливает передачу данных

Удаляет логическое соединение

Большинство администраторов настраивают межсетевые экраны таким образом, чтобы защитить сети от нежелательного проникновения в нее извне. Почти всегда разрешается установка TCP-соединений с удаленного порта 80 (HTTP для Всемирной паутины). Блокирование этого порта быстро выливается в недовольство клиентов. Однако большинство других портов блокируется, включая RSTP и RTP, которые, помимо других, используют и порты 554 и 5004. Таким образом, простейший способ передать сигнал через межсетевой экран — это заставить веб-сайт притвориться HTTP-сервером, отсылающим обычные HTTP-ответы (по крайней мере, для межсетевого экрана). Есть и другие преимущества TCP. Так как он обеспечивает надежность, он предоставляет клиенту точную копию медиа. Это позволяет пользователю легко перемотать файл на уже просмотренный кадр, не беспокоясь о потере данных. Наконец, TCP буферизует максимальную часть файла с максимально возможной скоростью. Когда место в буфере дешево (например, если для хранения используется диск), медиаплеер может загружать медиа по ходу просмотра. Когда загрузка завершена, пользователь может смотреть фильм без перерывов, даже если пропадает связь. Это качество полезно при использовании мобильных телефонов, так как возможность подключения может резко меняться при движении.

Недостаток TCP — это увеличение времени ожидания при начале просмотра (из-за запуска TCP), а также более высокий нижний предел. Однако это редко является проблемой, в том случае, если скорость передачи значительно превышает скорость, требуемую для воспроизведения.

7.4.4. Передача медиа в реальном времени

Не только записанное видео крайне популярно во Всемирной паутине. Передача медиа в реальном времени также пользуется большой популярностью. Как только стало возможным передавать аудио и видео через Интернет, коммерческие радио- и телестанции воспользовались этим. Вскоре появились студенческие станции, вещающие через Интернет. И студенты начали вести собственные программы.

Сегодня люди и компании всех размеров передают аудио и видео. Вещание в реальном времени стало колыбелью инноваций, возникли новые стандарты и технологии. Живое вещание через Интернет используется основными телестанциями. Его называют IPTV (IP Television — IP-телевидение). Такое же вещание используется и радиостанциями, например BBC. Оно называется интернет-радио. И IPTV, и интернет-радио вещают на весь мир, освещая различные события, от показов мод до мировых чемпионатов по футболу и отборочных состязаний по крикету. Живое вещание через IP используется провайдерами кабельного телевидения как технология построения собственных вещательных систем. И она часто используется малобюджетными проектами от сайтов для взрослых до зоопарков. С современной технологией практически каждый может начать живое вещание быстро и дешево.

Один из подходов к живому вещанию основан на записи программ на диск. Зрители могут подсоединиться к архивам сервера, выбрать любую программу, загрузить и прослушать ее. Подкаст (podcast) — это файл, полученный таким образом. Для программ, идущих по расписанию, также можно хранить контент после окончания передачи, так что архив будет отставать от живого вещания где-то на полчаса или даже меньше.

На самом деле, этот подход полностью совпадает с тем, что мы обсуждали касательно передачи мультимедиа. Он легко применим, все упомянутые нами техники работают в его рамках, и пользователи могут выбирать нужную им программу из архива.

Другой подход заключается в живом вещании через Интернет. Зрители подключаются к идущему медиапотоку, так же как к идущей по телевидению передаче. Однако медиаплееры предоставляют дополнительные возможности, такие как приостановка или перемотка назад. Живой медиаконтент будет продолжать передаваться и буфе-ризовываться плеером, пока пользователь не будет готов к просмотру. Со стороны браузера это выглядит в точности как передача сохраненного видео. Плееру не важно, отсылается ли контент в реальном времени, или же его источником является файл. Обычно плеер и не сможет этого определить (единственное отличие при живой передаче будет заключаться в отсутствии возможности перемотать контент вперед).

Учитывая сходство механизма с тем, что мы обсуждали выше, большая часть нашей дискуссии будет применима и к этому случаю, но есть и важные различия.

Важно отметить, что все еще есть необходимость в буферизации на стороне клиента, чтобы сгладить неустойчивость синхронизации (джиттер). На самом деле, при передаче контента в реальном времени часто потребуется буферизовывать большую часть данных (и это не с вязано с тем, что пользователь может приостанавливать воспроизведение). Когда передается файл, медиа может отправляться с более высокой скоростью, чем требуется для воспроизведения. В этом случае буфер быстро заполнится, что позволит компенсировать джиттер (и плеер остановит поток, если буферизация более не требуется). В отличие от этого при передаче контента в реальном времени скорости приема (и воспроизведения) совпадают со скоростями передачи (и генерации) контента. Быстрее контент отправляться не может. Следовательно, буфер должен быть больше, чтобы справиться со всем возможным джиттером. Как правило, задержки начала воспроизведения на 10-15 с обычно достаточно, так что это не является серьезной проблемой.

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

Схема многоадресной потоковой трансляции работает следующим образом. Сервер отправляет каждый пакет единожды, используя многоадресную передачу по IP группе адресатов (IP multicast). Все клиенты, желающие подключиться к передаче, присоединяются к группе при помощи IGMP, а не отсылая RTSP-сообщения на медиасервер, так как медиасервер уже отсылает живой поток (кроме случая, когда присоединяется первый зритель). Что и нужно для того, чтобы поток получался локально.

Так как многоадресная передача является сервисом доставки от одного ко многим, медиа передается в RTP-пакетах через UDP-транспорт. TCP работает только между одним отправителем и одним получателем. Так как UDP не обеспечивает надежности, некоторые пакеты могут быть потеряны. Чтобы сократить уровень потерь до приемлемого, мы можем использовать FEC и интерливинг, как и раньше.