«Разработка программно-аппаратного комплекса flash-видеовещания в Интернет» (стр. 3 )

4.4.2 Протоколы передачи видео по сети

4.4.2.1 RTP

Протокол RTP (Real-Time Transport Protocol) используется при передаче трафика реального времени. Протокол RTP переносит в своём заголовке данные, необходимые для восстановления голоса или видеоизображения в приёмном узле, а также данные о типе кодирования информации (JPEG, MPEG и т. п.). В заголовке данного протокола, в частности, передаются временная метка и номер пакета. Эти параметры позволяют при минимальных задержках определить порядок и момент декодирования каждого пакета, а также интерполировать потерянные пакеты. В качестве нижележащего протокола транспортного уровня, как правило, используется протокол UDP. RTP гарантирует доставку данных одному или более адресатам с задержкой в заданных пределах, т. е. данные могут быть воспроизведены в реальном времени.

При использовании этого протокола, для начала сессии передачи данных необходимо передать файл дескриптор сессии передачи (SDP файл), что не всегда удобно в реальных условиях.

4.4.2.2 RTSP

Протокол RTSP (Real-Time Streaming Protocol) предназначен для использования в системах, работающих с мультимедиа данными, и позволяющим клиенту удалённо управлять потоком данных с сервера, предоставляя возможность выполнения команд, таких как «Старт», «Стоп», а также доступа по времени к файлам, расположенным на сервере. По синтаксису и операциям протокол RTSP похож на HTTP. Однако между протоколами RTSP и HTTP есть ряд существенных различий. Одно из основных заключается в том, что в первом и сервер, и клиент способны генерировать запросы. Например, видеосервер может послать запрос для установки параметров воспроизведения определенного видео потока. Далее, протоколом RTSP предусматривается, что управление состоянием или связью должен осуществлять сервер, тогда как HTTP вообще никакого отношения к этому не имеет. TCP/IP обеспечивает надёжную доставку, а UDP - нет, поскольку TCP имеет встроенные механизмы контроля доставки и целостности данных. Однако TCP нельзя назвать лучшим решением для передачи мультимедиа, поскольку этот протокол добавляет в пакеты данных большое количество служебной информации. Для TCP главное - безошибочно передать данные, а время доставки вторично. С другой стороны, UDP использует гораздо меньше служебных данных, чем TCP, поэтому он лучше подходит для приложений, работающих с потоковыми данными, где на первый план выходит время доставки информации. Что касается пропусков и искажений пакетов, то решение этой проблемы возлагается на принимающую сторону. Сервис RTSP поддерживается набором инструкций, которыми обмениваются между собой сервер и клиент. Они отсылаются в виде RTSP-пакетов, содержащих установочные параметры для потока.

4.4.2.3 RTMP

Потоковые серверы дают возможность управлять передачей медиаданных, но в настройке и администрировании они более сложны, чем обыкновенные НТТР-серверы, а передача информации осуществляется не по стандартному HTTP, а по протоколу RTМP. RTMP (Real Time Messaging Protocol) протокол потоковой передачи данных, в основном используется для передачи видео- и аудио-потоков с камер через интернет. Также по этому протоколу происходит взаимодействие нескольких Flash приложений, которые могут работать на нескольких различных ПК. Серверная часть реализована авторами протокола корпорацией Adobe в Flash Media Server. Модули для сервера должны быть написаны на ActionScript. Протокол базируется на протоколе TCP и использует для передачи данных порт 1935. Также существуют другие варианты протокола:

§  RTMPT, который инкапсулируется в HTTP запросы, для обхода фаерволов

§  RTMPS, в нем используется HTTPS для обеспечения защиы передаваемых данных

Есть так же и альтернативы Adobe Flash Media Server от других компаний, реализованные на различных языках программирования, включая Python и Java. Например, компания Wowza Media Systems предлагает сервер Wowza Media Server Pro, модули для когорого должны быть написаны на Java. Группа энтузиастов методами reverse engineering разобрала протокол, и выпустила бесплатную версию сервера Red5. Сервер написан на Java. Модули для сервера так же должны быть написаны на Java. Также существует не вполне совместимый, но соблюдающий большую часть спецификаций протокола RTMP проект HaxeVideo, реализованный на специализированном языке HaXe для серверной виртуальной машины NeckoVM. Распространяется в исходных текстах и отличается низкой ресурсемкостью по сравнению с Java-реализациями, а также отсутствием необходимости ставить на сервер как Java, так и другие пакеты. Данный сервер не получил особого распространения. Подробнее медиасерверы будут рассмотрены в следующих главах.

3.4.2.4 RTMFP

Real Time Media Flow Protocol является неким развитием протокола RTMP, но не призван полностью его заменить. В некоторых случаях более оправданно использовать именно RTMFP. RTMFP появился вместе с выходом Adobe Flash Player 10, который пока не очень распространен у пользователей. Основные особенности RTMFP:

Основные преимущества протокола состоит в том, что возможно обеспечение меньших задержек из-за использования UDP и прямого соединения для передачи данных между клиентами. При этом медиасервер все равно используется для организации и управления соединениями между клиентами. То есть, использование этого протокола особенно выгодно при разработке приложения для передачи "живого" контента. Также возможна организация сети распределенной доставки контента, используя в качестве ячеек самих зрителей и их Интернет-каналы.

4.5 Серверы видеовещания в формате Flash Video

В предыдущих главах работы было выявлено что наиболее удобной для пользователей и наиболее перспективной для разработчиков технологией видеовещания (причем как и уже записанных файлов, так и видеовещания в прямом эфире) является технология Adobe Flash, описание которой можно найти в предыдущих главах. Серверы видеовещания еще могут называться медиасерверами. Как описывалось ранее, при использовании Adobe Flash передача видео и данных осуществляется по протоколу RTMP. Соответственно, существуют серверы видеовещания и серверы приложений, которые имеют поддержку этого протокола. Причем чаще всего сервер приложений и сервер вещания это одно и тоже. То есть, серверы имеют поддержку некоторого языка программирования, что позволяет разрабатывать серверные приложения, к которым могут подключаться клиенты Flash Player. В последнее время получает распространение p2p технология передачи данных напрямую между Flash клиентами с использованием протокола RTMFP.

Далее в этой главе рассматриваются наиболее распространенные на рынке серверные решения для передачи видео Flash приложениям и организации коммуникаций между ними.

4.5.1 Adobe Flash Media Streaming Server

Adobe Flash Media Streaming Server является "родным" решением от компании Adobe, которое предназначено именно для вещания видеофайлов или потоков в реальном времени. Стоит отдельно заметить что в данном сервере нет поддержки программирования на стороне сервера, то есть этот сервер не может быть использован в качестве сервера приложений, он изначально ориентирован только на вещание. Основные функции достаточно стандартны:

§  Dynamic Streaming

§  Для организации вещания не требуется программирования, только изменение некоторых настроек

§  Поддержка использования H264 и HE-AAC кодеков

§  Поддержка видеовещания в реальном времени

§  Поддержка мобильных клиентов, использующих Flash Lite 3

§  Логирование

§  Определение пропускной способности канала пользователя

§  Поддержка ОС Windows и Linux

Решение может использоваться для раздачи клиентам видеофайлов и live-потоков по протоколу RTMP. В качестве live-источника может использоваться Flash Player или Adobe Flash Media Live Encoder, а также сторонние приложения (такие как, например, Telestream Wirecast или FFMPEG) поддерживающие работу по протоколам RTMP. Также этот медиасервер поддерживает вещание по защищенному протоколу RTMPE со 128 битным шифрованием.

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

Стоимость приложения 995$. Исходный код полностью закрыт. Есть только спецификация одного из поддерживаемых протоколов RTMP. Версии под ОС Windows и Linux, текущая версия 3.5.

4.5.2 Adobe Flash Media Interactive Server

Adobe Flash Media Interactive Server -- это самое функциональное решение от компании Adobe, которое отличается от Adobe Flash Media Streaming Server поддержкой языка ActionScript 3 на стороне сервера, что позволяет создавать серверные приложения, которые используются для коммуникации между клиентскими Flash Player, работы с базами данных на сервере, и так далее. Основные функции Adobe Flash Media Interactive Server, которые добавляются по сравнению с более простой версией Adobe Flash Media Streaming Server:

§  Поддержка серверных скриптов

§  SharedObjects

§  Доставка контента пользователям не только по RTMP, но и по HTTP

§  Поддержка дополнений (плагинов)

§  Поддержка записи видео на стороне сервера

§  Автоматическое перенаправление потоков

§  Хорошо описанный API

§  Существует бесплатная версия для разработчиков приложений (с ограничением максимального количества подключений)

Таким образом, Adobe Flash Media Interactive Server позиционируется компанией как основное решение для разработки приложений с использованием платформы Flash и обладает теми же преимуществами, что и более простая редакция. В отличие от Adobe Flash Media Streaming Server, данное решение обладает полным функционалом и может не только передавать, но и записывать видеопотоки на стороне сервера и обрабатывать различные данные.

Также данная редакция необходима при создании сложных систем вещания видео, содержащих в себе несколько серверов, так как только данная редакция Adobe Flash Media Server может выступать в качестве "ретранслятора" видеопотоков. Также возможна организация аутентификации пользователей с использованием LDAP.

Существуют версии для ОС Windows Server и Linux, при этом оффициально Adobe поддерживает только Red Hat Enterprise Linux, но на самом деле сервер вполне работоспособен и с другими дистрибутивами. Стоимость поптавляет 4500$ для любой ОС, за единичную лицензию. Исходные коды закрыты, текущая версия 3.5.

4.5.3 Wowza MediaServer

Wowza MediaServer -- это еще одно пропиетарное решение. Разработчиком этого решения является компания WowzaMedia Systems. Решение, так же как и Red5, написано на языке Java, при этом оно обладает несколько большей производительностью, чем Red5. Функционально Wowza MediaServer ближе к Red5, чем к серверам от Adobe, но при этом имеет ряд отличий, которые выделяют его из остальных серверов, а именно:

§  Поддержка приема RTP/RTSP потоков от кодировщиков

§  Ретрансляция Shoutcast / Icy потоков

§  Запись на сервере любых форматов

§  Поддержка MPEG-TS

§  Поддержка мобильных устройств вроде iPhone

§  Сотрудничество с Amazon EC2

То есть компания Wowza предоставляет решение, которое "из коробки" обладает максимальным функционалом и очень хорошей поддержкой и документацией. Но, на самом деле, большинство возможностей данного продукта может быть реализовано и в Red5, посредством написания собственных приложений для сервера, но это может потребовать достаточно много времени.

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

Масштабируемость решения достаточна для организации сложных сетей доставки контента и реализована также как и конкурентов. Компания WowzaMedia имеет странную маркетинговую политику, например, при покупке perpetual версии сервера, его можно использовать только для себя и нельзя давать доступ для отправки и просмотра потоков на условиях аренды. В лицензии на версию perpetual указывается что можно показывать видео со своего сервера только на тех доменных именах, которыми вы владеете. То есть если строится сеть доставки контента, которую планируется сдавать в аренду, то придется покупать Wowza Media Server на условиях подписки стоимостью 65$ в месяц за один сервер.

Стоимость решения perpetual 995$. Поддерживаются ОС Windows и Linux. Исходный код закрыт. Текущая версия 2.0.0.

4.5.4 Red5

Red5 -- это полнофункциональный открытый медиасервер, являющийся, по сути, свободной реализацией Adobe Flash Media Server. Red5 написан на языке Java и может работать на любой платформе, для которой имеется виртуальная машина Java. Функционально Red5 практически идентичен Adobe Flash Media Interactive Server, поддерживаются те же функции, только серверные приложения пишутся также на языке Java, и поддержка ActionScript на серверной стороне полностью отсутствует. Основные функции сервера, выделяемые разработчиками:

§  Streaming Video (FLV, F4V, MP4)

§  Streaming Audio (MP3, F4A, M4A)

§  Recording Client Streams (FLV only)

§  Shared Objects

§  Live Stream Publishing

§  RTMPT - Tunneling over HTTP

§  RTMPS - RTMP over SSL

На первый взгляд отличия от платных решений Adobe минимальны, но на самом деле они выражаются в основном в стабильности работы. На самом деле стабильность Red5 достаточно высока для использования его в коммерческих проектах, просто требуется объем работ по тестированию и отладке приложений для этого сервера. Так, например, версия Red5 0.9.1 позволяет очень стабильно работать в связке с Xuggler-FFMPEG для организации Live вещания с платформы Linux. Достаточно существенным недостатком является отсутствие возможности записи видео в формате H.264 на стороне сервера и отсутствие запатентованной Adobe технологии Dynamic Streaming. Также то что сервер написан на языке Java накладывает некоторые требования на производительность сервера на котором будет работать это ПО, то есть требуется достаточно большой объем оперативной памяти, причем требования к объему памяти напрямую зависят от планируемой нагрузки на сервер. То есть, на каждого подключенного пользователя отводится достаточно существенный объем памяти, зато использование платформы Java позволяет организовать кроссплатформенность и хорошую масштабируемость.

Red5 можно назвать хорошим решением для организации вещания и доставки контента, учитывая, конечно, большую трудоемкость разработки, по сравнению с Flash Media Server. Также Red5 имеет достаточно хорошую документацию и различные возможности организации вещательной сети, как средствами самого сервера, так и средствами платформы.

Текущая версия 0.9.1. Работает в Java машине, в операционных системах Windows и Linux. Приложение распространяется бесплатно с открытыми исходными кодами по лицензии LGPL.

4.5.5 Другие медиасерверы

С начала 2010 года стало появляться все больше реализаций медиасерверов с поддержкой протокола RTMP. Это связвно с тем что осенью 2009 года компания Adobe представила общему обозрению спецификацию этого протокола. После этого события появилось достаточно много Open Source разработок в поддержкой RTMP, например:

§  RTMPd -- сервер для приложений видеовещания и коммуникации Flash, написанный на языке Си. Поддерживает вещание в реальном времени, видеокодеки VP6 и H264. Обладает очень хорошей производительностью, по сравнению с Java решениями. Также сервер позволяет орагнизовать Origin-Edge сеть доставки контента.

§  RTMPy -- сервер по функционалу схожий с RTMPd, но написанный на Python.

Также помимо серверов видеовещания, в связи с открытием спецификации протокола, поддержка RTMP появляется в различных распространенных Open Source приложениях, таких как FFmpeg и VLC. В открытых решениях поддержка самого протокола RTMP обычно реализована достаточно хорошо, так как спецификация Plain RTMP хорошо описывает протокол. А вот с реализациями RTMPT и RTMPS возникают проблемы, которые постепенно решаются разработчиками открытых медиасерверов.

Но все же основными игроками на рынке являются Adobe Flash Media Server в различных редакциях, Red5 и Wowza MediaServer. Функционал других серверов заметно меньше, но они могут использоваться для организации сервисов, не требующих большого функционала, но требовательных к количеству пользователей. В ближайшее время новые медиасерверы будут развиваться достаточно быстро и можно ожидать интересных программных решений от различных разработчиков.

4.6 Использование распределенных вычислительных сетей для доставки контента от медиасервера к пользователям

При использовании медиасерверов для доставки пользователям контента, причем как "Live" так и "On demand" контента, обычно используется сеть Интернет, в которой используется однонаправленная технология передачи пакетов unicast. Это значит что передача данных от сервера производится только одному конкретному адресату. Послать один пакет сразу нескольким (multicast) или абсолютно всем (broadcast) пользователям сети можно только в локальных сетях. В общественные сети могут отправляться только адресные (unicast) пакеты. Как следствие, каждый зритель, желающий посмотреть трансляцию, создает персональное (точка-точка) подключение к серверу и сервер лично этому абоненту передает поток информации. Из этого можно легко рассчитать максимальное количество подключений к серверу, зная ширину канала сервера и скорость видеопотока, передаваемого зрителям. Например, при использовании сервера подключенного гигабитным каналом, и скорости видеопотока 512 килобит в секунду, сервер может обслужить в пределе 2000 зрителей одновременно. На практике, конечно, такие показатели недостижимы из-за различных ограничений, но если рассматривать пример, приведенный выше, то около 1800 пользователей сервер точно сможет обслужить. В данном расчете также не учитываются аспекты производительности сервера, но при таких количествах зрителей (тысячи) производительности сервера обычно достаточно, основные проблемы возникают как раз с нагрузками на каналы связи.

В результате, для увеличения количества одновременно подключенных и просматривающих видео пользователей есть несколько различных вариантов:

§  Увеличение пропускной способности канала сервера

§  Уменьшение скорости видеопотока и соответственно его качества

§  Использование нескольких серверов, серверной сети

§  Пиринговые технологии

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

Так что наиболее применимый вариант это использование нескольких вещательных серверов. Далее рассмотрим распространенные схемы коммуникации между вещательными серверами.

4.6.1 Origin-Edge

Origin-Edge -- это наиболее распространенная схема связи между вещающими серверами, которая имеется у всех наиболее крупных игроков на рынке. Adobe Flash Media Interactive Server, Wowza MediaServer и Red5 поддерживают данный вид коммуникации.

Рисунок 16. Схема вещания Origin-Edge

Суть это варианта состоит в том, что один из серверов является основным (Origin). На этот сервер отправляются потоки от кодировщиков, на этом сервере хранятся видеофайлы для доступа по заказу. С этого же сервера контент доставляется части конечных клиентов, а также дополнительным серверам (Egde), которые в свою очередь также могут доставлять контент клиентам или другим дополнительным серверам. То есть у данного метода публикация потоков ничем не отличается от использования одного сервера, edge серверы настраиваются для автоматического получения и раздачи контента.

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

4.6.2 Пиринговые сети

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

Рисунок 17. Пиринговая схема вещания

Для организации пиринговой доставки видео в реальном времени в настоящее время достаточно часто используют SteamTorrent, это технология доставки видео, которая базируется на протоколе передачи файлов BitTorrent. Технология больше подходит для просмотра файлов из децентрализованной сети, чем для доставки live-видео, зато обладает всеми преимуществами BitTorrent, такими как обход NAT, что очень важно при пиринге. Сейчас эта технология не получила повсеместного применения из-за необходимости настройки и установки дополнительного программного обеспечения для организации просмотра видео.

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

Также достаточно интересной является возможность организации комбинированных сетей доставки контента, в которых часть клиентов использует прямое unicast соединение с сервером, часть использует multicast в своих локальных сетях, а оставшаяся часть клиентов использует пинринг. Скорее всего в ближайшем времени такие комбинированные технологии доставки видео получат широкое распространение, а сейчас такие технологии находятся только на стадии зарождения.

4.6.2 Использование Amazon EC2

Amazon EC2, Amazon Elastic Compute Cloud (EC2) -- это центральная часть облачной вычислительной платформы Amazon Web Services (AWS). EC2 позволяет пользователям арендовать виртуальные компьютеры, на которых можно запускать собственные операционные системы и их приложения. EC2 имеет отличную масштабируемость, предоставляя пользователям вэб сервис, через который возможно управление виртульными компьютерами пользователя. В терминологии Amazon виртуальный компьютер имеет название Instance.

Amazon Machine Image -- это образ операционной системы, запускаемый пользователем из вэб интерфейса управления. Могут использоваться как готовые образы, предоставляемые Amazon (в базе образов имеются образы большинства распространенных современных операционных систем), так и создаваться свои. Для организации виртуализации Amazon использует Xen, что позволяет использовать в качестве гостевых как unix, linux, так и windows системы.

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

Amazon предоставляет несколько вариантов виртуальных серверов, которые отличаются производительностью, количеством оперативной памяти, размером раздела под операционную систему. Стоимость аренды за час для различных по производительности вариантов разная, а стоимость трафика одинакова. Например, стандартный Instance имеет конфигурацию:

· 1.7 GB memory

· 1 EC2 Compute Unit (1 virtual core with 1 EC2 Compute Unit)

· 160 GB instance storage (150 GB plus 10 GB root partition)

· 32-bit platform

· I/O Performance: Moderate

· API name: m1.small

Стоимость аренды такого Instance $0.085 в час. А стоимость исходящего трафика составляет $0.15 за гигабайт, при использовании до 40 TB в месяц, при большем трафике стоимость еще ниже. Стоит заметить что система масштабируется так что скорость трафика не ограничивается, то есть можно иметь очень высокие скорости подключения, что удобно именно для организации трансляций. Для записи видео на серверной стороне в дополнение к EC2 можно использовать внешнее хранилище данных Amazon Simple Storage Service (S3).

В результате с EC2 можно использовать любые серверные решения для вещания видео, но особенно удобно выглядит использование Wowza Media Server, так как компания Wowza Media имеет соглашение с Amazon. При использовании сервера Wowza, можно не платить за собственную лицензию, а просто арендовать необходимый Instance на специальных условиях: $0.16 за час Small Instance в Европе и $0.15 за гигабайт переданных данных, также $5 за аренду Wowza Media Server 2. То есть при эпизодическом использовании трансляций очень удобно использовать вариант с EC2, вместо того чтобы поднимать собственные серверные мощности на различных площадках.

4.6.3 Использование Terracotta

Terracotta -- это решение для кластеризации и организации балансировки для Java приложений. Это решение может использоваться для организации кластеризации Edge серверов Red5, с использованием протокола RTMPT, причем поддерживается только этот протокол, так как используется HTTP балансировка нагрузки. Сервер Terracotta в данном случае управляет многими Edge серверами, которые принимают данные с нескольких Origin серверов.

Рисунок 18. Схема использования Terracotta совместно с сервером вещания Red5

Такое решение по балансировке может использоваться только с Red5, при этом нет необходимости постоянно иметь запущенные Edge серверы, в данном случае сервер Terracotta будет управлять запуском дополнительных Red5 по мере необходимости.

Такое решение имеет смысл использовать только при очень значительных нагрузках, когда могут потребоваться десятки, если не сотни Edge серверов для доставки контента конечным пользователям.

5. Специальная часть

В данной главе рассматриваются различные варианты организации портативных и стационарных студий для организации Интернет трансляций с использованием технологии Adobe Flash Video, выбор данной технологии произведен после обзора рынка в предыдущих главах работы. Рассматривается необходимое оборудования для различных вариантов студий. Также проводится обоснование выбора оборудования и программного обесценения, рассматриваются этапы разработки и доработки различных решений. Проводится обзор внедрений различных решений для организации Интернет вещания и многокамерных съемок.

Рисунок 19. Блок-схема общего вида Интернет трансляции

На блок схеме приведен общий случай Интернет трансляции с использованием технологиии Adobe Flash. Различные компоненты блок схемы были подробно рассмотрены с предыдущих главах работы, а в настоящей главе будет произведено обоснование выбора конкретных компонентов, разработаны методы коммуникации между ними и управления.

5.1 Портативная студия для организации Интернет трансляций

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

5.1.1 Аппаратная часть

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

5.1.1.1 Минимальная портативная схема для проведения трансляций

В самом минимальном случае Интернет трансляций представляет собой захват видео и звука с одной видеокамеры, причем неважно будет это качественная HDV камеры или веб камера, кодирование необходимым видео кодеком и отправка на вещательный сервер по протоколу RTMP. Для зрителей трансляции не важно что происходит в видео до отправки на сервер вещания и каким образом происходит доставка на север, зрители всегда могут посмотреть трансляцию с использованием Adobe Flash Player в своем браузере.

Рисунок 20. Самая минимальная схема проведения портативной Интернет трансляции

Итак, в самом минимальном случае, трансляция проводится при помощи одной камеры, при этом в качестве звукового источника используется микрофон камеры, ноутбука с операционной системой Windows и установленным приложением Adobe Flash Media Encoder, стоит отдельно заметить, что Adobe Flash Media Encoder не позволяет проводить коммутацию нескольких источников, то есть возможно только вести трансляцию с одной камеры, также Flash Media Encoder позволяет вести запись только в том видео что и оправлять на сервер, то есть только в сжатом кодеками виде. Естественно необходимо подключение к Интернет, скорость подключения зависит от качества трансляции и должна быть не менее чем (audio bitrate + video bitrate) * 1.5, для обеспечения плавного движения. В результате для самого минимального варианта проведения трансляции необходимо:

§  Ноутбук, с производительностью достаточной для кодирования видео кодеками On VP6 или H264 в реальном времени

§  Камера, подходят как DV, так и веб камеры, работа с которыми поддерживается операционной системой Windows

§  Соединительные кабели FireWire для FireWire камер и USB для USB камер

§  Дополнительные микрофоны

§  Удлинители для подключения к электросети

§  Ethernet патч корды для подключения к сети

§  Подключение к Интернет

Требования к производительности компьютера таковы:

§  Для кодирования видео стандартного разрешения до 720х576 кодеком VP6 достаточно ноутбука с процессором класса Pentium M с тактовой частотой от 1,73 Ггц и 1 гигабайтом оперативной памяти

§  Для кодирования видео стандартного разрешения до 720х576 кодеком H264 необходим ноутбук с двух - или более ядерным процессором класса Core 2 Duo или выше с тактовой частотой от 1.6 Ггц и минимум 1 гигабайтом оперативной памяти

§  Для кодирования видео высокого разрешения до 720p, то есть до 1280х720 необходим многоядерный процессор с частотой более 2.5 Ггц и не менее 2гигабайт оперативной памяти

§  Свободное место на жестком диске, если требуется запись выходного видео

Камеры, которые могут подключаться и использоваться совместно с Adobe Flash Media Encoder рассматривались в предыдущих главах работы. Дополнить самую минимальную схему проведения можно использованием внешнего микрофона, который может подключаться как к камере (если камера позволяет подключать внешние микрофоны), так и к линейному или микрофонному входу ноутбука. Приложение Adobe Flash Media Encoder позволяет использовать внешние звуковые источники. Процесс настройки и запуска такой трансляции будет рассмотрен далее в работе.

Также самая минимальная схема может быть реализована без использования Adobe Flash Media Encoder, а с использованием веб Flash приложения для захвата, кодирования и отправки видео на сервер. В этом случае обеспечиваются те же возможности, но при этом есть ограничение в используемых кодека, так как Flash Player позволяет кодировать видео только кодеком H263, который обеспечивает несколько худшее качество, чем рассмотренные выше. Но в данном случае все таки есть одно аппаратное ограничение, Flash приложение не позволяет использовать микрофоны DV камер, так что в этом случае. при использовании DV камеры требуется использование микрофона, подключенного непосредственно к ноутбуку.

Если есть необходимость использования нескольких камер, а также есть необходимость получить пригодную для последующего монтажа запись видео в исходном DV качестве, то тут используется минимальная схема с использованием программного обеспечения Dvswith, Ffmpeg и операционной системы Linux.

Рисунок 21. Минимальная схема портативной Интернет трансляции

В данном случае возможно подключение только DV видеокамер через интерфейс FireWire, но в данном случае появляется возможность коммутации камер и звуковых потоков в реальном времени. Возможность подключения внешних микрофонов как к камерам, так и к ноутбуку сохраняется. Подключение камер происходит по интерфейсу FireWire и поддерживаются только DV видеокамеры. На один контроллер ноутбука можно подключить до 2х видеокамер.

Рисунок 22, Разветвитель (концентратор) FireWire от компании Kramer Tools

Возможно использование FireWire разветвителей Kramer Tools. То есть к одному ноутбуку со встроенным контроллером FireWire можно подключить через разветвитель 2 камеры через встроенный контроллер и еще 2 дополнительные камеры через внешний 2х портовый ExpressCard FireWire контроллер. Но тут существует ограничение на длину кабеля Firewire между компьютером к которому подключены камеры и камерой, так как по стандарту FireWire максимальная длина кабеля ограничена 4,5 метрами, но на практике длина кабеля может быть до 8 метров. Если расстояние между камерой и компьютером требуется увеличить, то возможно использование повторителей Kramer Tools, которые позволяют усиливать сигнал в кабеле.

Рисунок 23. Express card контроллер FireWire