Study & DevО программировании и не только

Мультимедиа-программирование вместе с Red 5 server. Часть 1

Идея доставки по сетям Интернет мультимедиа в виде аудио и видеоматериалов совсем не нова. Еще добрых пятнадцать лет назад, в середине девяностых, было очевидно, что по мере повышения скорости работы телекоммуникационных сетей соотношение между информацией доставляемой через internet в форме текста и аудио-видео материалов будет неуклонно смещаться в сторону последней. И что самое приятное этот рост проявляется не в примитивной форме mp3 песен или фильмов загружаемых с torrent, а в форме организации телеконференций, ip телефонии, интерактивного телевидения и т.д. Технические возможности за последние три года подросли так сильно, а цены снизились до таких величин, что создать в internet собственный мультимедиа-сервер и развернуть на нем, да хоть сервис организации телеконференции, можно всего за пару месяцев. И это не будет требовать больших инвестиций ни в разработку специального программного обеспечения, ни в наем специалистов экстра-класса. Мультимедиа в internet – это уже совсем не “rocket science”.

В качестве цели этой серии материалов я ставлю перед собой задачу познакомить вас с доступным программным обеспечением и методиками разработки онлайн-приложений, активно использующих технологии потоковой доставки мультимедиа информации. Однако перед тем как мы углубимся в технику работы с red5 – известным, популярным и зарекомендовавшим себя мультимедиа сервером, необходимо сначала “сгрызть сухую корку теории”. Говорить о доставке через сеть internet мультимедиа хоть в форме аудио, хоть видео-содержимого было практически не возможно до тех пор, пока основным способом передачи трафика в internet были модемы. С предельной скоростью работы модема в 56 килобит/сек было трудно даже “скачивать” мультимедиа-файлы, не говоря уже об организации передачи аудио-видео трафика в режиме “почти” реального времени. Для оценки способности канала передавать потоковое мультимедиа от поставщика к конечному потребителю следует ввести понятие битрейта. Битрейт измеряется в килобитах/секунду, мегабитах/секунду и даже гигабитах/секунду. С одной стороны, битрейт измеряет полезную пропускную способность канала передачи данных. Здесь под полезной пропускной способностью понимается весь объем трафика за исключением служебного трафика, т.е. необходимого для обеспечения нормального функционирования канала (полная пропускная способность измеряется в бодах). Аудио-видео информация в окружающем нас мире представлена в аналоговой, т.е. непрерывной форме. Информация же в компьютерных сетях и системах представлена в форме дискретного сигнала. А раз так, то первым этапом становится задача оцифровки видео или аудио сигнала и перевода ее в форму следующих друг за другом ноликов и единичек. Выполнить подобное преобразование имеет смысл только с учетом того, что часть информации непрерывного мира будет утеряна, признана несущественной и проигнорирована при переводе ее в цифровую форму. Классический пример здесь – это работа алгоритма mp3. Вот как говорит об этом википедия:

MP3 является форматом сжатия с потерями, то есть часть звуковой информации, которую (согласно психоакустической модели) ухо человека воспринять не может или воспринимается не всеми людьми, из записи удаляется безвозвратно. Степень сжатия можно варьировать, в том числе в пределах одного файла. Интервал возможных значений битрейта составляет 8 — 320 кбит/c. Для сравнения, поток данных с обычного компакт-диска формата Audio-CD равен 1411,2 кбит/c при частоте дискретизации 44100 Гц

Чтобы не забыть, сразу скажу, что битрейт нельзя путать с частотой дискретизации, хотя между ними есть определенная связь. Но все же частота дискретизации – это частота с которой мы “нарезаем” непрерывную волну на маленькие кусочки и записываем показания амплитуды в этих точках, т.е. выполняем процедуру оцифровки аналогового сигнала.

Возвращаясь назад к определению того, что же такое битрейт, можно сказать, что вторая сторона битрейта – характеристика качества передаваемого потока данных. Для организации качественной передачи мультимедиа трафика в режиме реального времени важно найти разумный компромисс между тремя углами треугольника. Во-первых, предельной пропускной способностью канала т.е. тем максимальным значением битрейта, который мы можем пропустить через канал не получив задержек во времени и запаздывания сигнала. Далее идет качество сигнала, т.е. сколько мы можем выбросить “несущественных” компонент звука. И третий угол треугольника – это процессорные затраты на кодирование и декодирование сигнала. Очевидно, что есть различные алгоритмы сжатия сигнала, отличающиеся той нагрузкой, которую они дают на процессор. И если мы используем слишком хитрый алгоритм дешифровки сигнала, то можем столкнуться с неприятной ситуацией, когда хоть по сети передачи данных мы вовремя получили всю необходимую информацию для дешифровки сигнала. Но компьютер клиента оказался так слаб, что не успевает расшифровывать поступающий сигнал. Эффективным полагается способ, когда битрейт потока является переменным и плавает в определенном отрезке. Это так потому, что поток данных, не важно, видео или аудио, нуждается в разные моменты времени в разном объеме информации для кодирования (падая почти до нуля в моменты тишины или неподвижного кадра фильма).

Следующее понятие, которое нужно разобрать, это медиа-контейнеры и кодеки. Давайте задумаемся над тем из чего должен состоять файл с видео-фильмом, чтобы мы его могли комфортно просмотреть. Отложим на минуту технические нюансы кодирования информации, а вместо этого сосредоточимся на структурных частях. Очевидно, что фильм – это не только картинка, но и аудио-поток и часто не один (так мы имеем возможность в видеопроигрывателе переключаться между оригинальной озвучкой и переводом). Также фильм может идти с “внедренными” субтитрами. Содержимое фильма может быть разбито на отдельные части, главы с возможностью быстрого перехода по ним. Все эти виды информации хранятся как единая структурная единица внутри медиа-контейнера. Примеры медиаконтейнеров это 3gp, AVI, Ogg, Mov, RealMedia. Так, два файла с одинаковым расширением avi могут иметь совершенно различное внутреннее устройство. Т.е. видео и аудио-потоки могут быть закодированы различными комбинациями кодеков (например, видео кодируется с помощью divx, а звук с помощью mp3). На страничке википедии http://ru.wikipedia.org/wiki/Сравнение_мультимедиа-контейнеров можно найти сводную таблицу с перечнем всех известных мультимедиа-контейнеров и поддерживаемых ими возможностей. Таким образом, для того, чтобы просмотреть любой фильм используемая нами программа проигрывателя должна знать, как работать с форматом медиа-контейнера, а также иметь в наличии декодеры для всех алгоритмов, использованных для сжатия аудио-видео потоков. Учитывая, что задача, стоящая перед нами, - это организация потового вещания в internet, то мы должны ориентироваться на то поддержка какого формата является наиболее распространенной. К сожалению, до появления стандарта html5 не существовало единого способа внедрить в html-страничку видео-файл. На текущий момент браузеры firefix и google chrome “кушают” следующее выражение:
Это значит, что на страничке будет показано окошко проигрывателя с панелью управления, причем при открытии страницы автоматически начнется загрузка и показ файла “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). Еще одним известным мультимедиа-сервером, предназначенным для работы в среде java, является Wowza Media Server (http://www.wowzamedia.com/). Хотя это коммерческий продукт, но вы всегда можете начать знакомство с Wowza Media Server с редакции 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-приложениями.

« AlivePDF. Создание pdf-документов из flash

Мультимедиа-программирование вместе с Red 5 server. Часть 2 »