Применение технологий адаптивного HTTP-вещания для предоставления услуг OTT

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

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

Указанные ограничения не позволяют применять традиционные схемы IPTV-вещания для предоставления новых услуг – Television-Over-The-Top (OTT) и Multiscreen Delivery (вещание одного контента на различные типы оконечных устройств).

Что такое OTT и каковы его отличия от традиционного IPTV можно узнать в этой статье. Здесь упомянем лишь, что основным отличием OTT от IPTV является отсутствие привязки абонента к сети оператора – для просмотра телеканалов по технологии OTT нужны лишь компьютер (сеттоп-бокс), доступ в интернет с определенной пропускной способностью (обычно до 3 Мбит/с) и положительный баланс на счету абонента у OTT-провайдера.

Multiscreen Delivery позволяет пользователям получать доступ к контенту с различных оконечных устройств – персональных компьютеров, сеттоп-боксов, планшетных компьютеров и смартфонов. В общем случае, это может быть реализовано с помощью различных технологий, которые объединяются под одним названием – Adaptive HTTP Streaming (адаптивное вещание поверх протокола HTTP). При этом один входной видео поток преобразуется в несколько выходных, каждый из которых имеет разное разрешение (битрейт) и упакован в определенный контейнер, который затем разбивается на сегменты и передается по HTTP-протоколу. Каждая связка «разрешение + контейнер» предназначена для передачи по каналам с различной пропускной способностью. Например, потоки с низким битрейтом передаются на смартфоны и планшеты, которые обычно подключаются к интернету по относительно низкоскоростным беспроводным каналам и обладают небольшими ресурсами для декодирования, а потоки с большим битрейтом и высоким разрешением передаются на компьютеры и сеттоп-боксы, при этом битрейт потока может адаптивно изменяться в зависимости от доступной полосы пропускания или нагрузки на ЦП приемного устройства.

Основные области применения Multiscreen Delivery и Adaptive HTTP Streaming – это VOD и OTT, поэтому и рассматривать данные технологии следует совместно.

Общая информация о технологиях адаптивного HTTP-вещания

Рассмотрим цепь доставки контента от головной станции до абонента при организации услуг OTT (рисунок 1).

Прием

Прием каналов может выполняться из разных источников: спутники, наземное цифровое и аналоговое вещательное телевидение и т.д. На выходе головной станции (ГС), как и в традиционном IPTV, имеются MPEG-2 TS over IP multicast-потоки, передаваемые поверх UDP или RTP. Потоки на выходе ГС, как правило, сжаты с использованием различных кодеков и имеют разное разрешение.

Транскодирование

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

С целью гибкой адаптации к изменяющимся параметрам передачи для каждого входного сигнала энкодер должен генерировать как можно больше выходных потоков с различным битрейтом (как правило, хватает 4, но их количество может быть увеличено до 16). В таблице 1 приведены скорости потоков с разным разрешением (ориентировочный битрейт указан для кодека H.264):

*Примечание: битрейт потока зависит от разрешения видео, профиля и уровня сжатия, а также от реализации самого  энкодера

На выходе транскодеров имеется по несколько (как правило, по 4) «копий» каждого входного потока, сжатых с различными профилями. Данные потоки передаются в традиционном контейнере MPEG-2 TS over IP поверх протоколов UDP или RTP.

«Упаковка» в контейнеры

«Упаковку» сигналов в контейнеры, определяемые технологией доставки контента на оконечные устройства пользователей (см. далее), осуществляет специальное устройство – Packager. Помимо «упаковки», Packager должен поддерживать следующие функции:

•    Шифрование выходных сегментированных потоков с помощью DRM-системы, совместимой с определенной технологией доставки контента;
•    Возможность использования в качестве исходных сигналов как live-потоков (для организации услуг OTT), так и отдельных файлов (для организации услуг VOD).

Packager принимает потоки от транскодера, извлекает из контейнеров MPEG-2 TS полезную информацию и инкапсулирует ее в контейнеры, определяемые технологиями доставки контента. Затем Packager разбивает каждый выходной поток на сегменты (в оригинале – «chunks»), сохраняет их на диске и присваивает каждому сегменту уникальный URL. Таким образом, каждый сегмент может быть загружен с Packager’а с помощью команды «GET» по протоколу HTTP. Форматы контейнеров, которые используются серверами сегментации и упаковки потоков, рассмотрены ниже.

CDN

CDN расшифровывается как Content Delivery Network (сеть доставки контента) и представляет собой совокупность кэширующих серверов, которые принимают (или запрашивают) сегменты всех потоков от Packager’а с одной стороны и терминируют TCP-сессии оконечных пользователей с другой. Сервера CDN располагаются как можно ближе к оконечным пользователям с целью разгрузить опорную сеть от трафика и предотвратить ее перегрузки в часы наибольшей нагрузки, а также обеспечить высокое качество услуг даже при большом количестве абонентов.

Клиент

Как было упомянуто, в качестве оконечных пользовательских устройств могут выступать персональные и планшетные компьютеры, сеттоп-боксы и смартфоны. Очевидно, что данные устройства могут работать под управлением различных операционных систем (ОС). На сегодняшний день, существует 4 основных технологии доставки контента на абонентские устройства через сеть интернет, которые используются разными ОС. Неудивительно, что разработчиками данных технологий являются основные игроки рынка IT-индустрии:
•    Компания Apple®, со своим стандартом HLS;
•    Корпорация Google™, продвигающая свою технологию WebM;
•    Корпорация Microsoft® и ее стандарт Silverlight Smooth Streaming;
•    Компания Adobe с технологией HTTP dynamic Streaming.
Данные компании достигли больших успехов в области телекоммуникаций и в интернете, но, тем не менее, на момент написания статьи, ни одна из указанных технологий не стала общепринятым мировым стандартом вещания контента в интернете. Более того, в настоящее время ведется активная разработка технологии MPEG-DASH (см. далее), которая в ближайшем будущем может принять статус стандарта в области телекоммуникаций.

Apple HLS

Компания Apple представила технологию HTTP Live Streaming (HLS) в июне 2009 года в iPhone OS 3.0, что делает HLS старейшей из указанных технологий. На данный момент, HLS является самым распространенным протоколом вещания в интернете и используется всеми устройствами компании Apple (iPhone, iPad, iPod и т.д.), а также некоторыми программами и сеттоп-боксами.

Принцип работы

Компания Apple пошла по пути использования проверенных стандартов цифрового вещания, немного изменив их под нужды вещания поверх сети интернет. HLS работает с сегментированными потоками или файлами, упакованными в контейнер MPEG-2 TS. Для сжатия видео и аудио потоков в HLS используются широко распространенные кодеки MPEG H.264 и AAC соответственно. Ставка здесь сделана на тот факт, что чем меньше изменений будет внесено в существующие стандарты и технологии, тем быстрее будет происходить интеграция HLS в существующие системы.

Процесс организации вещания по протоколу HLS можно представить следующим образом:
1.Выполняется сжатие видео сигнала, полученного с прямой трансляции или из файла, в формат H.264/TS с различным выходным битрейтом (используя различные профили сжатия);
2.Полученный поток сегментируется для получения коротких «кусочков» (в оригинале – «chunks») контента, длиной, как правило, 10 секунд каждый;
3.Генерируется файл-плейлист (в формате m3u или m3u8, см. рисунок 2), который содержит ссылки на каждый сегмент потока;
4.Пользователь выполняет загрузку сначала плейлиста, а затем сегментированного потока с обыкновенного HTTP-сервера.

Рисунок 2

На рисунке 2 изображен пример файла-плейлиста протокола HLS. Плейлист содержит ссылки на 3 последних доступных сегмента. Тэг #EXT-X-MEDIA-SEQUENCE определяет последовательности для первого сегмента (505.ts), которая служит для совмещения отдельных сегментов из потоков с различными битрейтами (при адаптации к полосе пропускания канала). Тэг #EXT-X-TARGETDURATION:11 определяет длительность видео, передаваемого в сегментах (10 секунд); тэг #EXT-X-KEY:METHOD=NONE указывает на то, что сегменты передаются в незашифрованном виде. Тэги #EXTINF:10 несут информацию о длительности каждого сегмента.

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

1.Для  каждого канала или файла генерируется индексный файл (см. рисунок 3) с указанием различных профилей (соответствующих потокам разного качества);
2.Оконечное пользовательское устройство выбирает поток с наиболее подходящим битрейтом на основании того, сколько времени требуется для загрузки одного сегмента;
3.Каждый сегмент содержит 10 секунд видео, поэтому приемное устройство может автоматически с интервалом 10 секунд адаптироваться к изменяющимся параметрам передачи.

Рисунок 3

На рисунке 3 приведен вариант индексного файла-плейлиста протокола HLS, который содержит ссылки на 8 профилей одного и того же потока/файла.

Поддержка

Стандарт HLS поддерживают все устройства Apple, на которые установлена ОС iOS 3.0 и выше: iPhone, iPad и iPod, а также компьютеры Macintosh под управлением ОС MacOS® X Snow Leopard. Клиенты HLS используют QuickTime® X player, разработанный компанией Apple. Т.к. до сих пор не существует версия QuickTime X Player для Windows, то, фактически, нет «официальных» клиентов для HLS, кроме устройств, выпущенных компанией Apple.

Тем не менее, принципы, положенные в основу функционирования HLS, достаточно просты, поэтому разработать клиентское ПО для HLS-вещания сравнительно нетрудно. Verimatrix, Widevine, NDS, Latens и SecureMedia являются примерами компаний, которые разработали клиентское ПО для воспроизведения видео, передаваемого по стандарту HLS, и интегрировали его в свои DRM-системы.

Кроме того, клиентская часть HLS реализовывается также производителями сеттоп-боксов. Например, компании Airties, Netgem и Amino выпускают абонентские приставки, способные воспроизводить видео, передаваемое с HLS-сервера, а сервер ViaMotion Origin компании Anevia позволяет выполнять вещание видео с использованием данного протокола.

Преимущества

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

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

Наконец, использование контейнера MPEG-2 TS значительно упрощает интеграцию HLS в существующие системы цифрового телевидения.

Ограничения

Как отмечено выше, управление битрейтом потока осуществляется исключительно абонентским устройством. Данный «демократический» подход может стать источником некоторых проблем в том случае, если администратор хочет вручную настраивать качество видео для определенного контента.

Встроенная поддержка HLS отсутствует во всех основных WEB-браузерах.

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

DRM-шифрование применяется к целому сегменту. Это значит, что заголовки транспортного потока MPEG-2 TS также шифруются, что влечет невозможность использования некоторых дополнительных функций.

Наконец, в HLS не существует возможности передавать более одной аудио дорожки в потоке. В iOS5 введена возможность выбора альтернативного потока аудио, однако в данном случае количество аудио дорожек ограничивается двумя, в то время как с помощью технологий Smooth Streaming и MPEG-DASH может передаваться неограниченное количество аудио потоков.

Microsoft Smooth Streaming

Smooth Streaming – это протокол вещания видео контента, который был представлен как расширение технологии Silverlight 3.0. Впервые его спецификации были опубликованы компанией Microsoft в сентябре 2009 года. В качестве видео и аудио кодеков компания Microsoft выбрала H.264 и AAC соответственно с целью обеспечения возможности простого аппаратного декодирования потоков HD-качества (720p/1080p). Тем не менее, Smooth Streaming также совместим с кодеками WMA, SMPTE VC-1, а также всеми остальными кодеками, которые поддерживаются контейнером 3GP.

Принцип работы

Smooth Streaming работает с контейнером PIFF (Protected Interoperable File Format), при этом общие принципы работы протокола весьма похожи на функционирование HLS: видео и аудио информация сжимается с использованием кодеков H.264 и AAC (или VC-1/WMA) соответственно, полученные потоки сегментируются, мультиплексируются в контейнер PIFF и распространяются по протоколу HTTP через web-сервер и CDN.

Для получения видео потока пользователь сначала загружает с сервера файл-manifest в формате XML, в котором содержится информация о доступных аудио и видео дорожках и их битрейте. Затем клиент запрашивает один или более сегментов, которые передаются поверх протокола HTTP. Подобно HLS, управление битрейтом в Smooth Streaming осуществляет клиентская сторона. Однако, в отличие от HLS, где ссылки на сегменты представлены в явном виде в файле-плейлисте, файл-manifest протокола MSS содержит информацию, которая позволяет клиентскому устройству сгенерировать ссылки на сегменты на основании данных синхронизации, содержащихся в потоке. Поэтому при вещании live-потоков клиенту не требуется периодически заново загружать файл-manifest. Ниже приведен формат запроса файла-manifest’а, а на рисунке 4 – его содержание:

http://{serverName}/{PublishingPointPath}/{PublishingPointName}.isml/manifest

Рисунок 4

В приведенном примере элементы t=”249…” указывают на временные метки сегментов, которые доступны и могут быть загружены с сервера. Данные записи конвертируются во временные метки в ссылках на загрузку сегментов. Загруженные сегменты содержат временные метки одного или двух следующих сегментов, таким образом, постоянное обновление файла-manifest’а не требуется.

При использовании данного протокола с VoD, файл-manifest сразу содержит информацию про временные метки для всех сегментов.

Ниже приведены примеры ссылок на аудио и видео дорожки потока:

http://sourcehost/local/2/mysticSmooth.isml/QualityLevels(350000)/Fragments(video=2489452460333)
http://sourcehost/local/2/mysticSmooth.isml/QualityLevels(31466)/Fragments(audio-eng=2489450962444)

Здесь параметр QualityLevel указывает на профиль (битрейт) текущего сегмента, а параметры video= и audio-eng= непосредственно указывают на сегменты, которые должны быть загружены.

Также следует отметить, что в Smooth Streaming относительно легко могут быть интегрированы DRM-системы. Более того, существует возможность использования нескольких уровней DRM в одном и том же файле.

Поддержка

Поддержка Smooth Streaming осуществляется компанией Microsoft, при этом спецификации протокола доступны в открытом виде. Некоторые производители вещательных серверов (например, Anevia) предлагают решения, полностью совместимые со спецификациями, выпущенными Microsoft. Также в 2011 году компания Microsoft выпустила клиентскую библиотеку Smooth Streaming для ОС iOS и Android.

Преимущества

Smooth Streaming поддерживает наличие нескольких аудио дорожек и нескольких дорожек субтитров в потоке. Для получения наиболее качественного изображения, плеер Microsoft Silverligh перед выбором потока с большим битрейтом анализирует возможности устройства. Также Smooth Streaming поддерживает интеграцию любой DRM, помимо Microsoft PlayReady. Положительным также является тот факт, что компания Microsoft предоставляет весьма подробные спецификации с большим количеством примеров, что значительно облегчает понимание функционирования и внедрение технологии.

Ограничения

Хотя технология Smooth Streaming разрабатывалась исключительно для вещания через web, сам плеер всегда управляется плагином Silverlight. Даже браузер Microsoft Internet Explorer требует установки дополнительного плагина для функционирования Smooth Streaming. Так же, как и в HLS, управление битрейтом выполняется исключительно с клиентской стороны, что делает невозможной «тонкую» ручную настройку сети. Наконец, Smooth Streaming использует патентованные аудио и видео кодеки, а поэтому за его использование, возможно, придется платить в будущем.

Adobe HTTP Dynamic Streaming

Если проанализировать весь видео контент, который был передан по сети интернет с начала столетия, то окажется, что наибольшая его часть была передана с помощью технологии, разработанной компанией Adobe. Тем не менее, данный контент, как правило, представляет собой видео клипы, записанные в формате .FLV, не защищенные DRM и не предназначенные для передачи с адаптивно изменяющимся битрейтом.

Технология Adobe Flash (ранее – Macromedia Flash) была представлена в 1996 году и, согласно информации компании Adobe, в 2010 году использовалась 98 % пользователями сети интернет в США.

Принцип работы

Технически, принцип функционирования HDS очень похож на принцип работы протокола Microsoft Smooth Streaming. Видео поток состоит из:
•    Manifest-файла в формате XML с расширением .f4m (см. рисунок 5);
•    Сегментированных файлов, которые содержат фрагменты потока MPEG-4 и имеют расширение .f4f;
•    Индексных файлов с расширением .f4x, которые содержат специфическую информацию о фрагментах, расположенных внутри сегментированных файлов.

Рисунок 5

Как видно, manifest-файл содержит загрузочную информацию (в оригинале – «bootstrap») и помогает плееру определить, с какого сегмента следует начинать воспроизведение. Также в данном файле содержится информация о доступных битрейтах.

HDS поддерживает видео кодеки H.264 и VP6 и аудио кодеки AAC и MP3. Ниже приведен формат запроса сегмента потока для протокола HDS:

http://server_and_path/QualityModifierSeg’segment_number’–Frag’fragment_number’

Единственной системой DRM, интегрированной с HDS, является собственная система компании Adobe под названием Flash Access. Данная система обладает большим количеством функций и дает возможность гибко изменять параметры доступа к контенту, а также позволяет кодировать не только полезную нагрузку, но и информацию протоколов транспортного уровня. Недостатком данной системы является достаточно большая нагрузка на ЦП, что может привести к невозможности использования данной DRM на бюджетных сеттоп-боксах и других абонентских устройствах, которые не обладают достаточной производительностью.

Преимущества

На данный момент, практически любой компьютер в мире может воспроизводить потоки Adobe HDS. Данный стандарт для использования с VOD-приложениями достаточно полно и доступно описан компанией Adobe, кроме того, для HDS существуют подробные примеры написания исходного кода.

Ограничения

Единственной системой DRM, которая поддерживается HDS, является Flash Access. Несмотря на то, что HDS достаточно полно описан для использования с VOD-приложениями, нет практически никакой информации про использование DRM Flash Access (особенно с live-потоками). Подобно Apple HLS, нет возможности передавать более одной аудио дорожки с помощью HDS. Существуют бета-версии протокола, которые позволяют выбирать альтернативную аудио дорожку, но только для VOD-файлов, а не для live-потоков.

Google WebM

WebM был представлен компанией Google в мае 2010 года как полностью открытый стандарт, не требующий уплаты лицензионных отчислений при его использовании. Для того, чтобы это обеспечить, компания Google использовала видео кодек VP8, аудио кодек Vorbis и контейнер, известный под названием Matroska. Через несколько дней после анонсирования стандарта WebM, о его поддержке заявили более сорока производителей программного и аппаратного обеспечения, включая ARM, Intel, Mozilla Foundation и Opera Software.

Принцип работы

Функционирование стандарта WebM отличается от других технологий. При его использовании не требуется сегментирования исходной информации, т.к. с позиции WebM один медиа-поток представляется в виде одного файла.

Вещание live-потоков или VOD-файлов по протоколу WebM осуществляется следующим образом:
•    Видео и аудио контент сжимается с помощью кодеков VP8 и Vorbis соответственно (одни и те же потоки или файлы энкодируются с различным битрейтом);
•    Сжатый контент мультиплексируется в файл, который должен автоматически обновляться в случае live-вещания;
•    Полученный WebM-файл попадает к абоненту через HTTP-сервер.

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

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

Поддержка

WebM поддерживается практически всеми современными браузерами, работающими под ОС Windows, MacOS X и Linux OS. Также технология WebM поддерживается последними HD-телевизорами компании Sony и сеттоп-боксами “Revue” компании Logitech. Наконец, поддержка WebM была добавлена в ОС Android начиная с версии 2.3.3. Как известно, ОС Android используется многими производителями мобильных устройств, такими как Motorola, HTC, Samsung и Sony-Ericsson, поэтому технология WebM может стать весьма популярной уже в ближайшее время.

Преимущества

Выбор контейнера Matroska представляется весьма интересным решением: в нем используется двоичный формат EBML, произошедший от XML, что дает возможность расширять функционал контейнера без нарушения обратной совместимости со старыми версиями. Например, сейчас Matroska имеет систему меню (аналог разделов в формате DVD), поддерживает наличие нескольких аудио и видео дорожек, 3D-конент, субтитры и т.д. Более того, Matroska требует меньше пропускной способности для передачи служебной информации, чем контейнер TS, что очень важно при передаче видео на мобильные устройства. Также к преимуществам стоит отнести встроенную поддержку WebM основными web-браузерами.

Ограничения

Основным недостатком технологии WebM является небольшое количество доступных микросхем, поддерживающих аппаратное декодирование кодека VP8 (распространение мобильных устройств на платформе Nvidia Tegra 2, которая обладает поддержкой аппаратного декодирования как H.264, так и VP8, частично решает данную проблему). Вторым недостатком является отсутствие поддержки WebM сеттоп-боксами (решается установкой браузера Opera). Также существуют проблемы с кэшированием потоков WebM, которое может выполняться только с использованием специальных вещательных серверов и не может осуществлять традиционными методами. Официально, в WebM отсутствует поддержка DRM-систем. Тем не менее, при необходимости в контейнер Matroska может быть сравнительно легко добавлена поддержка шифрования. В связи с тем, что не так давно Google приобрела компанию Widevine, можно предположить, что в скором будущем в WebM появится поддержка DRM.

MPEG-DASH

Описанные выше технологии берут свое начало из рынка интернет-услуг и не имеют прямых корней в телекоммуникационной индустрии. Эту «брешь» заполнили организации MPEG-LA и ISO выпустив свой собственный стандарт по адаптивному вещанию поверх протокола HTTP – MPEG-DASH (Dynamic Adaptive Streaming over HTTP). Первая черновая спецификация протокола DASH была выпущена в феврале 2011 года.

Принцип работы

Функционирование протокола подобно уже описанным технологиям: существует manifest-файл формата XML, который выступает в роли плейлиста и содержит информацию описательного характера (как в Microsoft Smooth Streaming). Формат контейнера может быть одним из следующих:
•    Файл формата ISO, похожий на контейнер MPEG-4 (фрагментированный MPEG-4 как в Smooth Streaming или Adobe Dynamic Streaming);
•    MPEG-2 Transport Stream (как в HLS);
•    Контейнер 3GP.

Протокол MPEG-DASH опционально может содержать дополнительную функцию: сегмент инициализации. Данный сегмент имеет формат MPEG2-TS и содержит отдельную программу, служебную информацию, относящуюся к данной программе (PAT, PMT), а также необязательную информацию о кодеке и DRM. Наличие сегмента инициализации дает возможность не дублировать данную информацию в последующих сегментах.

На рисунке 6 приведена последовательность формирования сегментированного потока (файла) в случае использования MPEG-DASH:

В MPEG-DASH используется DRM-система под названием UltraViolet, которая позволяет воспроизводить однажды приобретенный контент на любых устройствах (концепция «Buy once, play it anywhere»). Разработка данной системы осуществляется консорциумом под названием Digital Entertainment Content Ecosystem (DECE), в который входят более 70 членов, среди которых есть Sony, Microsoft, Google (Widevine), Adobe, Cisco, HP, IBM, Intel, Motorola Mobility (теперь Google), Samsung, LG Electronics и студии, производящие контент, такие как Warner Bros, NBC Universal, Fox, Paramount, Sony Pictures и Lionsgate.

Преимущества

С чисто технической точки зрения, MPEG-DASH является наиболее совершенным из всех описанных протоколов. Т.к. данный протокол продвигается организациями ISO и MPEG-LA, в будущем он вполне может стать стандартом в области телекоммуникаций. Также заслуживает внимания DRM-система UltraViolet со своей философией «Buy once, play anywhere», т.к. лишь небольшое количество пользователей используют оборудование одного производителя для воспроизведения контента.

Ограничения

С клиентской точки зрения, ограничение состоит в том, что на данный момент всего лишь несколько плееров могут корректно принимать и воспроизводить поток MPEG-DASH. Также, в настоящее время, спецификации протокола существуют лишь в черновом варианте. Наконец, компании Apple и Walt Disney являются противниками разработки и внедрения DRM-системы UltraViolet, что может стать препятствием на пути принятия стандарта.

Закрытие контента, управление абонентами и организация дополнительных услуг в OTT

Описанные технологии позволяют решить задачу доставки контента от места производства (хранения) к оконечному потребителю, однако они не позволяют контролировать доступ к контенту и выполнять его закрытие. Решение данных задач осуществляется соответственно с помощью промежуточного ПО и систем условного доступа. С коммерческой точки зрения, без использования промежуточного ПО и систем условного доступа теряется вообще всякий смысл организации услуг OTT, т.к. проконтролировать процесс доступа к контенту и его доставки становится практически невозможно.

Как и в традиционных сетях IPTV, при предоставлении услуг по технологии OTT задачи управления абонентской базой и организации дополнительных услуг решаются при помощи промежуточного ПО (Middleware). В данном случае функционирование Middleware осуществляется по протоколу HTTP и ничем не отличается от традиционных IPTV-сетей. Со стороны абонента используются либо сеттоп-боксы, интегрированные с Middleware определенного производителя, либо специальное ПО, которое устанавливается на компьютер, планшет или смартфон.

Неудивительно, что компании, занимающиеся разработкой IPTV Middleware, начали выпускать версии своего ПО и для сетей OTT. Примером может служить BeeSmart Middleware (рисунок 7), которое может быть использовано как в традиционных IPTV проектах, так и в OTT-решениях.

Рисунок 7

Закрытие контента при предоставлении OTT-услуг играет еще большую роль, чем в сетях IPTV. Т.к. в OTT контент передается по открытым, не принадлежащим провайдеру сетям, вероятность его «перехвата» посторонними лицами более высока, чем традиционном IPTV.

Как показано на рисунке 1, во всех описанных технологиях задача «закрытия» контента (скремблирование) выполняется Packager’ом с использованием DRM серверов сторонних производителей. Многие компании, занимающиеся разработкой систем закрытия контента для IPTV и DVB-сетей, начали выпускать решения и для OTT. Примером могут служить компании Verimatrix (рисунок 8) и Nagravision.

Normal 0 false false false RU X-NONE X-NONE MicrosoftInternetExplorer4