Red5: практика работы с потоковым мультимедиа. Часть 1
Идея доставки по сетям Интернет мультимедиа в виде аудио- и видеоматериалов совсем не нова. Еще добрых пятнадцать лет назад, в середине девяностых, было очевидно, что по мере повышения скорости работы телекоммуникационных сетей соотношение между информацией, доставляемой через internet в форме текста и аудио/видеоматериалов, будет неуклонно смещаться в сторону последней. И что самое приятное, этот рост проявляется не в примитивной форме MP3 песен или фильмов, загружаемых с torrent, а в форме организации телеконференций, ip-телефонии, интерактивного телевидения и т.д. Технические возможности за последние три года подросли так сильно, а цены снизились до таких величин, что создать в internet собственный мультимедиа-сервер и развернуть на нем да хоть сервис организации телеконференции, можно всего за пару месяцев. И это не будет требовать больших инвестиций ни в разработку специального программного обеспечения, ни в наем специалистов экстра-класса. Мультимедиа в internet – это уже совсем не “rocket science”.
В качестве цели этой серии материалов я ставлю перед собой задачу познакомить вас с доступным программным обеспечением и методиками разработки онлайн-приложений, активно использующих технологии потоковой доставки мультимедиа-информации. Однако перед тем как мы углубимся в технику работы с red5 – известным, популярным и зарекомендовавшим себя мультимедиа-сервером, необходимо сначала “сгрызть сухую корку теории”. Говорить о доставке через сеть internet мультимедиа хоть в форме аудио, хоть видеосодержимого было практически невозможно до тех пор, пока основным способом передачи трафика в internet были модемы. С предельной скоростью работы модема в 56 килобит/сек было трудно даже “скачивать” мультимедиа- файлы, не говоря уже об организации передачи аудио/видеотрафика в режиме “почти” реального времени. Для оценки способности канала передавать потоковое мультимедиа от поставщика к конечному потребителю следует ввести понятие битрейта. Битрейт измеряется в килобитах/секунду, мегабитах/секунду и даже гигабитах/секунду. С одной стороны, битрейт измеряет полезную пропускную способность канала передачи данных. Здесь под полезной пропускной способностью понимается весь объем трафика за исключением служебного трафика, т.е. необходимого для обеспечения нормального функционирования канала (полная пропускная способность измеряется в бодах). Аудио/видеоинформация в окружающем нас мире представлена в аналоговой, т.е. непрерывной форме. Информация же в компьютерных сетях и системах представлена в форме дискретного сигнала. А раз так, то первым этапом становится задача оцифровки видео- или аудиосигнала и перевода ее в форму следующих друг за другом ноликов и единичек. Выполнить подобное преобразование имеет смысл только с учетом того, что часть информации непрерывного мира будет утеряна, признана несущественной и проигнорирована при переводе ее в цифровую форму. Классический пример здесь – это работа алгоритма MP3. Вот как говорит об этом википедия:
MP3 является форматом сжатия с потерями, то есть часть звуковой информации, которую (согласно психоакустической модели) ухо человека воспринять не может или воспринимается не всеми людьми, из записи удаляется безвозвратно. Степень сжатия можно варьировать, в том числе в пределах одного файла. Интервал возможных значений битрейта составляет 8-320 кбит/c. Для сравнения, поток данных с обычного компакт-диска формата Audio-CD равен 1411,2 кбит/c при частоте дискретизации 44.100 Гц
Чтобы не забыть, сразу скажу, что битрейт нельзя путать с частотой дискретизации, хотя между ними есть определенная связь. Но все же частота дискретизации – это частота, с которой мы “нарезаем” непрерывную волну на маленькие кусочки и записываем показания амплитуды в этих точках, т.е. выполняем процедуру оцифровки аналогового сигнала.
Возвращаясь назад к определению того, что же такое битрейт, можно сказать, что вторая сторона битрейта – характеристика качества передаваемого потока данных. Для организации качественной передачи мультимедиа-трафика в режиме реального времени важно найти разумный компромисс между тремя углами треугольника. Во-первых, предельной пропускной способностью канала, т.е. тем максимальным значением битрейта, который мы можем пропустить через канал, не получив задержек во времени и запаздывания сигнала. Далее идет качество сигнала, т.е. сколько мы можем выбросить “несущественных” компонент звука. И третий угол треугольника – это процессорные затраты на кодирование и декодирование сигнала. Очевидно, что есть различные алгоритмы сжатия сигнала, отличающиеся той нагрузкой, которую они дают на процессор. И если мы используем слишком хитрый алгоритм дешифровки сигнала, то можем столкнуться с неприятной ситуацией, когда хоть по сети передачи данных мы вовремя получили всю необходимую информацию для дешифровки сигнала, но компьютер клиента оказался так слаб, что не успевает расшифровывать поступающий сигнал. Эффективным полагается способ, когда битрейт потока является переменным и плавает в определенном отрезке. Это так потому, что поток данных, неважно, видео или аудио, нуждается в разные моменты времени в разном объеме информации для кодирования (падая почти до нуля в моменты тишины или неподвижного кадра фильма).
Следующее понятие, которое нужно разобрать, это медиаконтейнеры и кодеки. Давайте задумаемся над тем, из чего должен состоять файл с видеофильмом, чтобы мы могли его комфортно просмотреть. Отложим на минуту технические нюансы кодирования информации, а вместо этого сосредоточимся на структурных частях. Очевидно, что фильм – это не только картинка, но и аудиопоток и часто не один (так, мы имеем возможность в видеопроигрывателе переключаться между оригинальной озвучкой и переводом). Также фильм может идти с “внедренными” субтитрами. Содержимое фильма может быть разбито на отдельные части, главы с возможностью быстрого перехода по ним. Все эти виды информации хранятся как единая структурная единица внутри медиаконтейнера. Примеры медиаконтейнеров — это 3gp, AVI, Ogg, Mov, RealMedia. Так, два файла с одинаковым расширением avi могут иметь совершенно различное внутреннее устройство. Т.е. видео- и аудиопотоки могут быть закодированы различными комбинациями кодеков (например, видео кодируется с помощью divx, а звук с помощью mp3). На страничке википедии http://ru.wikipedia.org/wiki/Сравнение_мультимедиа-контейнеров можно найти сводную таблицу с перечнем всех известных мультимедиа-контейнеров и поддерживаемых ими возможностей. Таким образом, для того, чтобы просмотреть любой фильм, используемая нами программа проигрывателя должна знать, как работать с форматом медиаконтейнера, а также иметь в наличии декодеры для всех алгоритмов, использованных для сжатия аудио/видеопотоков. Учитывая, что задача, стоящая перед нами, - это организация потового вещания в internet, то мы должны ориентироваться на то, поддержка какого формата является наиболее распространенной. К сожалению, до появления стандарта html5 не существовало единого способа внедрить в html-страничку видеофайл. На текущий момент браузеры firefix и google chrome “кушают” следующее выражение:
<video src="kino.ogx" controls="true" autoplay="true" width="320" height="240" poster="before_loaded.png">
your browser does not support the video tag
</video>
Это значит, что на страничке будет показано окошко проигрывателя с панелью управления, причем при открытии страницы автоматически начнется загрузка и показ файла “kino.ogx ”. До того момента, пока файл будет подгружаться, на экране будет показан файл с картинкой-постером “before_loaded.png”. Как выглядит подобный проигрыватель – это забота конкретного браузера, но на рис.1 я показал пример для google chrome. По аналогии с тегом video существует тег audio для вставки аудиоматериалов. К сожалению, надеяться на то, что в скором времени можно будет вставлять в веб-странички видеоролики, не приходится. Причина в том, что файл “kino.ogx” – это медиаконтейнер, разработанный сообществом Xiph.Org, свободный и открытый. Но само изображение и звук кодируются конкретными кодеками. И если их не будет на компьютере клиента, то посмотреть кино не получится. Хорошим решением было бы заставить всех производителей браузеров включить поддержку некоторого джентльменского набора кодеков и в идеале использовать только opensource кодеки, например Theora для видео и Vorbis для аудио. К сожалению, в середине лета 2009 г. появилось сообщение, что стандарт html 5 не будет накладывать никаких требований поддержки кодеков (подробнее на сайте http://www.nixp.ru/news/9818). Одним словом, закладываться на перспективные теги html5 и долго, и бесполезно. На текущий момент для вставки видео в страницы используется flash-проигрыватели, которые проигрывают flv-файлы. Итак, что же такое flv-файл?
Технически flv – это расширение для flash video. Flash video – это медиаконтейнер (наподобие avi), внутри которого хранятся аудио- и видеопотоки. Если посмотреть историю, то поддержка загружаемого через протокол RTMP видео в flash появилась с 6-ой версии (flash mx, 2002 год). Тогда для кодирования использовался кодек Sorenson Sparc. В версии Flash Player 7 появилась возможность загружать видео по протоколу http. В восьмой версии добавился новый кодек TrueMotion VP6. А после выпуска 9-ой версии flash player количество нововведений резко выросло: практически каждый крупный апдейт flash player-а включал в себя и обновление видеоподсистемы: видеокодек H.264, используемый для поддержки видео с высоким разрешением, аудиокодек AAC, более эффективный, чем MP3, еще поддержка полноэкранного режима и т.д. Изменения есть и в flash player 10: аудиокодек Speex Audio и новый протокол для доставки видеопотока Real Time Media Flow Protocol. Что особенно важно — flash не является “дорогой с односторонним движением”, и мы можем не только принимать с сервера видео/аудиопотоки, но и захватить с помощью веб-камеры и микрофона поток данных и передать его на сервер с целью последующей ретрансляции этих потоков другим клиентам. На такой нехитрой методике и построены всевозможные приложения для организации телеконференций.
Теперь рассмотрим такой аспект доставки видео, как транспорт. Есть два возможных пути внедрения видео в веб-страницу, точнее в flash-ролик. Во- первых, flv-файл можно сделать частью swf-файла. Естественно, что пользователь может начать просмотр видеопотока, не дожидаясь завершения загрузки самого swf-файла. Но такой подход неудобен – гораздо лучше, если файл с видеопотоком хранится отдельно от основного приложения. Загружаться flv-файл может либо по протоколу HTTP, либо по протоколу RTMP. RTMP расшифровывается как Real Time Messaging Protocol и представляет собой разработанный компанией macromedia/adobe проприетарный протокол, в основном предназначенный для передачи аудио/видеопотоков через internet. Также через RTMP протокол могут проходить remote-call вызовы расположенных на веб-сервере процедур с какой-то бизнес-логикой. Здесь кодирование передаваемых данных выполняется с помощью протокола AMF. Для передачи данных через протокол RTMP зарезервирован порт 1935, но в тех случаях, когда такой трафик не пропускается через какой-то сегмент сети, можно использовать протокол RTMPT, который прячет (т.е. “туннелирует”) RTMP-трафик внутри HTTP-трафика. Еще есть протокол RTMPS, который прячет RTMP-трафик, уже внутри HTTPS-трафика. Интересно, что спецификация протокола RTMP была официально открыта только летом этого года. Теперь перечислим то, какие есть конкретные серверы, поддерживающие RTMP- протокол. Исторически первым был сервер от создателя протокола RTMP (т.е. компании macromedia/adobe) – Adobe Flash Media Server (http://www.adobe.com/products/flashmediaserver/). Продукт этот имеет несколько версий с разными возможностями и стоимостью. К примеру, если вы планируете отдавать RTMP-трафик с Adobe Flash Media Server менее чем десяти клиентам одновременно, то ничего не нужно платить. Flash Media Streaming Server и Flash Media Interactive Server ограничений на количество клиентов не содержат, но отличаются списком возможностей и ценой ($995 и $4500 соответственно). Еще недавно появился написанный на C++ opensource сервер http://mammothserver.org/.
Тема этой серии статей – написанный на java медиасервер red5 (http://code.google.com/p/red5/). Red5 разрабатывается с 2005 года и последней стабильной версией является 0.8 (в разработке 0.9). На базе red5 был разработан коммерческий продукт Wowza Media Server (http://www.wowzamedia.com/). Что касается его модели лицензирования, то есть редакция Wowza Pro10, которая также как и Adobe Flash Media Server разрешает не более десяти одновременных клиентских подключений и ничего не стоит. Что касается версий без ограничений и с поддержкой MPEG-TS стандарта, то их стоимость плавает в районе $995 на сервер (подробнее на http://www.wowzamedia.com/pricing.html). Из экзотических вариантов еще можно назвать haXeVideo server (http://haxevideo.org/). Этот медиасервер написан на языке haXe и требует для своей работы установленной на сервере виртуальной машины NekoVM. Также могу назвать написанный на Ruby медиасервер RubyIZUMI (http://code.google.com/p/rubyizumi/). Заметьте, что все описанные выше серверы требуют для своей работы особого хостинга, т.е. вы не сможете запустить их на “дешевом” виртуальном хостинге за $100 в год. Не говоря уже о том, что объемы прокачиваемого трафика очень скоро заставят вас познакомиться со службой поддержки хостинга и не в самом приятном смысле этого слова. Надеюсь, это не сочтут за рекламу, но мне недавно от хостера моего сайта active.by пришло письмо с описанием новой услуги cтриминга, т.е. организации вещания в internet аудио/видеопотоков. Подробнее, что это такое, можно узнать на сайте http://active.by/ru-by/services/hosting/streaming/.
Чтобы закрыть теоретическую страницу рассказа о работе с потоковым мультимедиа, я хотел бы рассказать еще об одной стороне процесса “раздачи” видеопотоков – задачах маршрутизации потоков данных. Когда мы говорим о классическом процессе передачи информации между клиентом и сервером, то полагаем, что связь устанавливается между двумя компьютерами и только. Сам же трафик по пути из Беларуси в Австралию проходит через большое число промежуточных узлов маршрутизаторов, которые решают задачи логистики, связанные с поиском наилучшего маршрута с точки зрения скорости передачи данных и равномерного заполнения каналов передачи трафика. Очевидно, что нужно стараться максимально экономить (отдавать как можно меньше) трафик – это и деньги, и скорость работы медиасервера. Если мы разрабатываем приложение — галерею фильмов для онлайн-просмотра, то придумать возможные способы оптимизации очень трудно. Поскольку запросы клиентов на просмотр фильмов поступают в различное и не связанное между собой время, и к тому же запросы наверняка будут идти к разным фильмам. А вот если рассмотреть задачу организации вещания в internet, например, идущей в прямом эфире церемонии открытия Олимпийских игр или какого-либо еще подобного репортажа, то мы увидим, что один и тот же поток данных может быть отдан большому количеству клиентов в один и тот же момент времени. А можем ли мы каким-то образом организовать связь от сервера не к каждому из клиентов по отдельности, а ко всем сразу, чтобы не дублировать потоки данных? К примеру, подобная техника пригодится и при организации онлайн-конференций. Ведь каждый из участников должен получать поток с изображением и речью всех остальных участников (на практике только одного человека, выступающего в данный момент времени).
Итак, новые термины: unicast, broadcast и multicast. Unicast – это схема передачи данных, в которой пакет с информацией получает только один адресат с конкретным ip-адресом. Broadcast означает широковещательную передачу, в ходе которой пакеты с информацией получают все компьютеры, расположенные в рамках одного сегмента сети. Очевидно, что широковещательный трафик не может быть пропущен в том виде “как есть” через границы вашего сегмента сети (например, локальной сети в офисе). То есть нельзя сделать так, чтобы ваше сообщение получили сразу все компьютеры в inetrnet-е. В качестве примера могу вспомнить случай, когда мне лет пять назад пришлось разрабатывать приложение для ВУЗа, которое использовали для повышения качества обучения. В нем изображение экрана с одного (учительского) рабочего места передавалось на все остальные рабочие места (студентов), так чтобы студенты видели у себя то, что показывает преподаватель. Какое-то время, до появления в наличии у учебного заведения проектора, эта программка пользовать спросом. Третий способ передачи информации – multicast — предполагает одновременную отправку информации нескольким компьютерам сети. Но важно, что эти компьютеры могут находиться в различных сегментах сети. К примеру, если человек хочет участвовать в конференции, то он посылает запрос на присоединение к группе и получает новый IP-адрес в специально зарезервированном для multicast-рассылок диапазоне от 224.0.0.0 до 239.255.255.255, и далее работает “магия” маршрутизации. То есть когда медиасервер отправляет пакет с данными на ip- адрес, принадлежащий группе, то его получат все вошедшие в эту группу клиенты.
На этом теория закончилась. В следующий раз я перейду к практике работы с red5 и организации его “общения” с flash-приложениями.
black-zorro@tut.by black-zorro.com
В качестве цели этой серии материалов я ставлю перед собой задачу познакомить вас с доступным программным обеспечением и методиками разработки онлайн-приложений, активно использующих технологии потоковой доставки мультимедиа-информации. Однако перед тем как мы углубимся в технику работы с red5 – известным, популярным и зарекомендовавшим себя мультимедиа-сервером, необходимо сначала “сгрызть сухую корку теории”. Говорить о доставке через сеть internet мультимедиа хоть в форме аудио, хоть видеосодержимого было практически невозможно до тех пор, пока основным способом передачи трафика в internet были модемы. С предельной скоростью работы модема в 56 килобит/сек было трудно даже “скачивать” мультимедиа- файлы, не говоря уже об организации передачи аудио/видеотрафика в режиме “почти” реального времени. Для оценки способности канала передавать потоковое мультимедиа от поставщика к конечному потребителю следует ввести понятие битрейта. Битрейт измеряется в килобитах/секунду, мегабитах/секунду и даже гигабитах/секунду. С одной стороны, битрейт измеряет полезную пропускную способность канала передачи данных. Здесь под полезной пропускной способностью понимается весь объем трафика за исключением служебного трафика, т.е. необходимого для обеспечения нормального функционирования канала (полная пропускная способность измеряется в бодах). Аудио/видеоинформация в окружающем нас мире представлена в аналоговой, т.е. непрерывной форме. Информация же в компьютерных сетях и системах представлена в форме дискретного сигнала. А раз так, то первым этапом становится задача оцифровки видео- или аудиосигнала и перевода ее в форму следующих друг за другом ноликов и единичек. Выполнить подобное преобразование имеет смысл только с учетом того, что часть информации непрерывного мира будет утеряна, признана несущественной и проигнорирована при переводе ее в цифровую форму. Классический пример здесь – это работа алгоритма MP3. Вот как говорит об этом википедия:
MP3 является форматом сжатия с потерями, то есть часть звуковой информации, которую (согласно психоакустической модели) ухо человека воспринять не может или воспринимается не всеми людьми, из записи удаляется безвозвратно. Степень сжатия можно варьировать, в том числе в пределах одного файла. Интервал возможных значений битрейта составляет 8-320 кбит/c. Для сравнения, поток данных с обычного компакт-диска формата Audio-CD равен 1411,2 кбит/c при частоте дискретизации 44.100 Гц
Чтобы не забыть, сразу скажу, что битрейт нельзя путать с частотой дискретизации, хотя между ними есть определенная связь. Но все же частота дискретизации – это частота, с которой мы “нарезаем” непрерывную волну на маленькие кусочки и записываем показания амплитуды в этих точках, т.е. выполняем процедуру оцифровки аналогового сигнала.
Возвращаясь назад к определению того, что же такое битрейт, можно сказать, что вторая сторона битрейта – характеристика качества передаваемого потока данных. Для организации качественной передачи мультимедиа-трафика в режиме реального времени важно найти разумный компромисс между тремя углами треугольника. Во-первых, предельной пропускной способностью канала, т.е. тем максимальным значением битрейта, который мы можем пропустить через канал, не получив задержек во времени и запаздывания сигнала. Далее идет качество сигнала, т.е. сколько мы можем выбросить “несущественных” компонент звука. И третий угол треугольника – это процессорные затраты на кодирование и декодирование сигнала. Очевидно, что есть различные алгоритмы сжатия сигнала, отличающиеся той нагрузкой, которую они дают на процессор. И если мы используем слишком хитрый алгоритм дешифровки сигнала, то можем столкнуться с неприятной ситуацией, когда хоть по сети передачи данных мы вовремя получили всю необходимую информацию для дешифровки сигнала, но компьютер клиента оказался так слаб, что не успевает расшифровывать поступающий сигнал. Эффективным полагается способ, когда битрейт потока является переменным и плавает в определенном отрезке. Это так потому, что поток данных, неважно, видео или аудио, нуждается в разные моменты времени в разном объеме информации для кодирования (падая почти до нуля в моменты тишины или неподвижного кадра фильма).
Следующее понятие, которое нужно разобрать, это медиаконтейнеры и кодеки. Давайте задумаемся над тем, из чего должен состоять файл с видеофильмом, чтобы мы могли его комфортно просмотреть. Отложим на минуту технические нюансы кодирования информации, а вместо этого сосредоточимся на структурных частях. Очевидно, что фильм – это не только картинка, но и аудиопоток и часто не один (так, мы имеем возможность в видеопроигрывателе переключаться между оригинальной озвучкой и переводом). Также фильм может идти с “внедренными” субтитрами. Содержимое фильма может быть разбито на отдельные части, главы с возможностью быстрого перехода по ним. Все эти виды информации хранятся как единая структурная единица внутри медиаконтейнера. Примеры медиаконтейнеров — это 3gp, AVI, Ogg, Mov, RealMedia. Так, два файла с одинаковым расширением avi могут иметь совершенно различное внутреннее устройство. Т.е. видео- и аудиопотоки могут быть закодированы различными комбинациями кодеков (например, видео кодируется с помощью divx, а звук с помощью mp3). На страничке википедии http://ru.wikipedia.org/wiki/Сравнение_мультимедиа-контейнеров можно найти сводную таблицу с перечнем всех известных мультимедиа-контейнеров и поддерживаемых ими возможностей. Таким образом, для того, чтобы просмотреть любой фильм, используемая нами программа проигрывателя должна знать, как работать с форматом медиаконтейнера, а также иметь в наличии декодеры для всех алгоритмов, использованных для сжатия аудио/видеопотоков. Учитывая, что задача, стоящая перед нами, - это организация потового вещания в internet, то мы должны ориентироваться на то, поддержка какого формата является наиболее распространенной. К сожалению, до появления стандарта html5 не существовало единого способа внедрить в html-страничку видеофайл. На текущий момент браузеры firefix и google chrome “кушают” следующее выражение:
<video src="kino.ogx" controls="true" autoplay="true" width="320" height="240" poster="before_loaded.png">
your browser does not support the video tag
</video>
Технически flv – это расширение для flash video. Flash video – это медиаконтейнер (наподобие avi), внутри которого хранятся аудио- и видеопотоки. Если посмотреть историю, то поддержка загружаемого через протокол RTMP видео в flash появилась с 6-ой версии (flash mx, 2002 год). Тогда для кодирования использовался кодек Sorenson Sparc. В версии Flash Player 7 появилась возможность загружать видео по протоколу http. В восьмой версии добавился новый кодек TrueMotion VP6. А после выпуска 9-ой версии flash player количество нововведений резко выросло: практически каждый крупный апдейт flash player-а включал в себя и обновление видеоподсистемы: видеокодек H.264, используемый для поддержки видео с высоким разрешением, аудиокодек AAC, более эффективный, чем MP3, еще поддержка полноэкранного режима и т.д. Изменения есть и в flash player 10: аудиокодек Speex Audio и новый протокол для доставки видеопотока Real Time Media Flow Protocol. Что особенно важно — flash не является “дорогой с односторонним движением”, и мы можем не только принимать с сервера видео/аудиопотоки, но и захватить с помощью веб-камеры и микрофона поток данных и передать его на сервер с целью последующей ретрансляции этих потоков другим клиентам. На такой нехитрой методике и построены всевозможные приложения для организации телеконференций.
Теперь рассмотрим такой аспект доставки видео, как транспорт. Есть два возможных пути внедрения видео в веб-страницу, точнее в flash-ролик. Во- первых, flv-файл можно сделать частью swf-файла. Естественно, что пользователь может начать просмотр видеопотока, не дожидаясь завершения загрузки самого swf-файла. Но такой подход неудобен – гораздо лучше, если файл с видеопотоком хранится отдельно от основного приложения. Загружаться flv-файл может либо по протоколу HTTP, либо по протоколу RTMP. RTMP расшифровывается как Real Time Messaging Protocol и представляет собой разработанный компанией macromedia/adobe проприетарный протокол, в основном предназначенный для передачи аудио/видеопотоков через internet. Также через RTMP протокол могут проходить remote-call вызовы расположенных на веб-сервере процедур с какой-то бизнес-логикой. Здесь кодирование передаваемых данных выполняется с помощью протокола AMF. Для передачи данных через протокол RTMP зарезервирован порт 1935, но в тех случаях, когда такой трафик не пропускается через какой-то сегмент сети, можно использовать протокол RTMPT, который прячет (т.е. “туннелирует”) RTMP-трафик внутри HTTP-трафика. Еще есть протокол RTMPS, который прячет RTMP-трафик, уже внутри HTTPS-трафика. Интересно, что спецификация протокола RTMP была официально открыта только летом этого года. Теперь перечислим то, какие есть конкретные серверы, поддерживающие RTMP- протокол. Исторически первым был сервер от создателя протокола RTMP (т.е. компании macromedia/adobe) – Adobe Flash Media Server (http://www.adobe.com/products/flashmediaserver/). Продукт этот имеет несколько версий с разными возможностями и стоимостью. К примеру, если вы планируете отдавать RTMP-трафик с Adobe Flash Media Server менее чем десяти клиентам одновременно, то ничего не нужно платить. Flash Media Streaming Server и Flash Media Interactive Server ограничений на количество клиентов не содержат, но отличаются списком возможностей и ценой ($995 и $4500 соответственно). Еще недавно появился написанный на C++ opensource сервер http://mammothserver.org/.
Тема этой серии статей – написанный на java медиасервер red5 (http://code.google.com/p/red5/). Red5 разрабатывается с 2005 года и последней стабильной версией является 0.8 (в разработке 0.9). На базе red5 был разработан коммерческий продукт Wowza Media Server (http://www.wowzamedia.com/). Что касается его модели лицензирования, то есть редакция Wowza Pro10, которая также как и Adobe Flash Media Server разрешает не более десяти одновременных клиентских подключений и ничего не стоит. Что касается версий без ограничений и с поддержкой MPEG-TS стандарта, то их стоимость плавает в районе $995 на сервер (подробнее на http://www.wowzamedia.com/pricing.html). Из экзотических вариантов еще можно назвать haXeVideo server (http://haxevideo.org/). Этот медиасервер написан на языке haXe и требует для своей работы установленной на сервере виртуальной машины NekoVM. Также могу назвать написанный на Ruby медиасервер RubyIZUMI (http://code.google.com/p/rubyizumi/). Заметьте, что все описанные выше серверы требуют для своей работы особого хостинга, т.е. вы не сможете запустить их на “дешевом” виртуальном хостинге за $100 в год. Не говоря уже о том, что объемы прокачиваемого трафика очень скоро заставят вас познакомиться со службой поддержки хостинга и не в самом приятном смысле этого слова. Надеюсь, это не сочтут за рекламу, но мне недавно от хостера моего сайта active.by пришло письмо с описанием новой услуги cтриминга, т.е. организации вещания в internet аудио/видеопотоков. Подробнее, что это такое, можно узнать на сайте http://active.by/ru-by/services/hosting/streaming/.
Чтобы закрыть теоретическую страницу рассказа о работе с потоковым мультимедиа, я хотел бы рассказать еще об одной стороне процесса “раздачи” видеопотоков – задачах маршрутизации потоков данных. Когда мы говорим о классическом процессе передачи информации между клиентом и сервером, то полагаем, что связь устанавливается между двумя компьютерами и только. Сам же трафик по пути из Беларуси в Австралию проходит через большое число промежуточных узлов маршрутизаторов, которые решают задачи логистики, связанные с поиском наилучшего маршрута с точки зрения скорости передачи данных и равномерного заполнения каналов передачи трафика. Очевидно, что нужно стараться максимально экономить (отдавать как можно меньше) трафик – это и деньги, и скорость работы медиасервера. Если мы разрабатываем приложение — галерею фильмов для онлайн-просмотра, то придумать возможные способы оптимизации очень трудно. Поскольку запросы клиентов на просмотр фильмов поступают в различное и не связанное между собой время, и к тому же запросы наверняка будут идти к разным фильмам. А вот если рассмотреть задачу организации вещания в internet, например, идущей в прямом эфире церемонии открытия Олимпийских игр или какого-либо еще подобного репортажа, то мы увидим, что один и тот же поток данных может быть отдан большому количеству клиентов в один и тот же момент времени. А можем ли мы каким-то образом организовать связь от сервера не к каждому из клиентов по отдельности, а ко всем сразу, чтобы не дублировать потоки данных? К примеру, подобная техника пригодится и при организации онлайн-конференций. Ведь каждый из участников должен получать поток с изображением и речью всех остальных участников (на практике только одного человека, выступающего в данный момент времени).
Итак, новые термины: unicast, broadcast и multicast. Unicast – это схема передачи данных, в которой пакет с информацией получает только один адресат с конкретным ip-адресом. Broadcast означает широковещательную передачу, в ходе которой пакеты с информацией получают все компьютеры, расположенные в рамках одного сегмента сети. Очевидно, что широковещательный трафик не может быть пропущен в том виде “как есть” через границы вашего сегмента сети (например, локальной сети в офисе). То есть нельзя сделать так, чтобы ваше сообщение получили сразу все компьютеры в inetrnet-е. В качестве примера могу вспомнить случай, когда мне лет пять назад пришлось разрабатывать приложение для ВУЗа, которое использовали для повышения качества обучения. В нем изображение экрана с одного (учительского) рабочего места передавалось на все остальные рабочие места (студентов), так чтобы студенты видели у себя то, что показывает преподаватель. Какое-то время, до появления в наличии у учебного заведения проектора, эта программка пользовать спросом. Третий способ передачи информации – multicast — предполагает одновременную отправку информации нескольким компьютерам сети. Но важно, что эти компьютеры могут находиться в различных сегментах сети. К примеру, если человек хочет участвовать в конференции, то он посылает запрос на присоединение к группе и получает новый IP-адрес в специально зарезервированном для multicast-рассылок диапазоне от 224.0.0.0 до 239.255.255.255, и далее работает “магия” маршрутизации. То есть когда медиасервер отправляет пакет с данными на ip- адрес, принадлежащий группе, то его получат все вошедшие в эту группу клиенты.
На этом теория закончилась. В следующий раз я перейду к практике работы с red5 и организации его “общения” с flash-приложениями.
black-zorro@tut.by black-zorro.com
Компьютерная газета. Статья была опубликована в номере 34 за 2009 год в рубрике программирование
