+380 44 323 88 88
ул. Маричанская, 18,
г. Киев, Украина, 03040
Написать нам

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

13 января 2012

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

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

К сожалению, с точки зрения операторов ситуация выглядит несколько сложней. В традиционном 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):

Кол-во точек по

горизонтали

Кол-во точек по

вертикали

Ориентировочный битрейт

видео потока*

1280 720 3 Мбит/с
960 540 1,5 Мбит/с
864 486 1,25 Мбит/с
640 360 750 кбит/с – 1,0 Мбит/с
416 240 500 кбит/с
320 180 150 – 350 кбит/с

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

На выходе транскодеров имеется по несколько (как правило, по 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-сервера.

#EXTM3U
#EXT-X-KEY:METHOD=NONE
#EXT-X-TARGETDURATION:11
#EXT-X-MEDIA-SEQUENCE:494
 
#EXT-X-KEY:METHOD=NONE
#EXTINF:10,505.ts
505.ts
#EXTINF:10,506.ts
506.ts
#EXTINF:10,507.ts
507.ts

Рисунок 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 секунд адаптироваться к изменяющимся параметрам передачи.

#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=531475
mystic_S1/mnf.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=381481
mystic_S2/mnf.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=531461
mystic_S3/mnf.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=781452
mystic_S4/mnf.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1031452
mystic_S5/mnf.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1281452
mystic_S6/mnf.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1531464
mystic_S7/mnf.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=3031464
mystic_S8/mnf.m3u8

Рисунок 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

 

<SmoothStreamingMedia MajorVersion="2" MinorVersion="0" TimeScale="10000000" Duration="0" LookAheadFragmentCount="2"
IsLive="TRUE" DVRWindowLength="300000000">
<StreamIndex Type="video" QualityLevels="7" TimeScale="10000000" Name="video" Chunks="14"
Url="QualityLevels({bitrate})/Fragments(video={start time})" MaxWidth="1280" MaxHeight="720"
DisplayWidth="1280" DisplayHeight="720">
<QualityLevel Index="0" Bitrate="350000"
CodecPrivateData="00000001274D401F9A6282833F3E022000007D20001D4C12800000000128EE3880" MaxWidth="320"
MaxHeight="180" FourCC="H264" NALUnitLengthField="4"/>
<QualityLevel Index="1" Bitrate="500000"
CodecPrivateData="00000001274D401F9A628343F6022000007D20001D4C12800000000128EE3880" MaxWidth="416"
MaxHeight="240" FourCC="H264" NALUnitLengthField="4"/>
<QualityLevel Index="2" Bitrate="750000"
CodecPrivateData="00000001274D401F9A6281405FF2E022000007D20001D4C1280000000128EE3880" MaxWidth="640"
MaxHeight="360" FourCC="H264" NALUnitLengthField="4"/>
<QualityLevel Index="3" Bitrate="1000000"
CodecPrivateData="00000001274D401F9A6281405FF2E022000007D20001D4C1280000000128EE3880" MaxWidth="640"
MaxHeight="360" FourCC="H264" NALUnitLengthField="4"/>
<QualityLevel Index="4" Bitrate="1250000"
CodecPrivateData="00000001274D40289A6281B07FF36022000007D20001D4C1280000000128EE3880" MaxWidth="864"
MaxHeight="486" FourCC="H264" NALUnitLengthField="4"/>
<QualityLevel Index="5" Bitrate="1500000"
CodecPrivateData="00000001274D40289A6281E022FDE022000007D20001D4C1280000000128EE3880" MaxWidth="960"
MaxHeight="540" FourCC="H264" NALUnitLengthField="4"/>
<QualityLevel Index="6" Bitrate="3000000"
CodecPrivateData="00000001274D40289A6280A00B76022000007D20001D4C12800000000128EE3880" MaxWidth="1280"
MaxHeight="720" FourCC="H264" NALUnitLengthField="4"/>
<c t="2489302977667"/>
<c t="2489324332333"/>
<c t="2489345687000"/>
<c t="2489367041667"/>
<c t="2489388396333"/>
<c t="2489409751000"/>
<c t="2489431105667"/>
<c t="2489452460333"/>
<c t="2489473815000"/>
<c t="2489495169667"/>
<c t="2489516524333"/>
<c t="2489537879000"/>
<c t="2489559233667"/>
<c t="2489580588333" d="21354667"/>
</StreamIndex>
<StreamIndex Type="audio" QualityLevels="4" TimeScale="10000000" Language="eng" Name="audio_eng" Chunks="14"
Url="QualityLevels({bitrate})/Fragments(audio_eng={start time})">
<QualityLevel Index="0" Bitrate="31466" CodecPrivateData="1190" SamplingRate="48000" Channels="2"
BitsPerSample="16" PacketSize="4" AudioTag="255" FourCC="AACL"/>
<QualityLevel Index="1" Bitrate="31469" CodecPrivateData="1190" SamplingRate="48000" Channels="2"
BitsPerSample="16" PacketSize="4" AudioTag="255" FourCC="AACL"/>
<QualityLevel Index="2" Bitrate="31472" CodecPrivateData="1190" SamplingRate="48000" Channels="2"
BitsPerSample="16" PacketSize="4" AudioTag="255" FourCC="AACL"/>
<QualityLevel Index="3" Bitrate="31481" CodecPrivateData="1190" SamplingRate="48000" Channels="2"
BitsPerSample="16" PacketSize="4" AudioTag="255" FourCC="AACL"/>
<c t="2489301415778"/>
<c t="2489322749111"/>
<c t="2489344082444"/>
<c t="2489365415778"/>
<c t="2489386749111"/>
<c t="2489408295778"/>
<c t="2489429629111"/>
<c t="2489450962444"/>
<c t="2489472295778"/>
<c t="2489493629111"/>
<c t="2489514962444"/>
<c t="2489536295778"/>
<c t="2489557629111"/>
<c t="2489578962444" d="21333334"/>
</StreamIndex>
</SmoothStreamingMedia>

 

Рисунок 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, которые содержат специфическую информацию о фрагментах, расположенных внутри сегментированных файлов.

 

<manifest>
<id>USP</id>
<startTime>2006-07-24T07:15:00+01:00</startTime>
<duration>0</duration>
<mimeType>video/mp4</mimeType>
<streamType>live</streamType>
<deliveryType>streaming</deliveryType>
<bootstrapInfo profile="named" url="mysticHDS.bootstrap"/>
<media url="mysticHDS-audio_eng=31492-video=3000000-" bitrate="3031" width="1280" height="720"/>
<media url="mysticHDS-audio_eng=31492-video=1500000-" bitrate="1531" width="960" height="540"/>
<media url="mysticHDS-audio_eng=31492-video=1250000-" bitrate="1281" width="864" height="486"/>
<media url="mysticHDS-audio_eng=31492-video=1000000-" bitrate="1031" width="640" height="360"/>
<media url="mysticHDS-audio_eng=31492-video=750000-" bitrate="781" width="640" height="360"/>
<media url="mysticHDS-audio_eng=31492-video=500000-" bitrate="531" width="416" height="240"/>
<media url="mysticHDS-audio_eng=31469-video=350000-" bitrate="381" width="320" height="180"/>
</manifest>

 

Рисунок 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

 

В 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-решениях.

 

BeeSmart Middleware может быть использовано как в традиционных IPTV проектах, так и в OTTV-решениях

 

Рисунок 7

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


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

 

 

 
Решения для OTTV

Рисунок 8

Решения ведущих мировых производителей в области организации адаптивного НТТР-вещания

Компания «ДЕПС» сотрудничает с ведущими фирмами-производителями OTT-решений в мире, среди которых отдельно следует отметить компании RGB Networks, Anevia и Envivio. Подходы к реализации задач адаптивного НТТР-вещания у данных компаний отличаются, а их программные и аппаратные продукты могут быть использованы операторами различного масштаба. Ниже рассмотрены подходы различных производителей к организации предоставления OTT-услуг.

Решение компании RGB Networks для организации адаптивного НТТР-вещания

Компания RGB Networks предлагает решение, наиболее подходящее для OTT-операторов крупного и среднего масштаба (от единиц до нескольких сотен каналов).


Подход компании RGB Networks практически не отличается от рассмотренной ранее модели (см. рисунок 9). Сигналы, принятые ГС IPTV, транскодируются с различным выходным битрейтом с помощью специализированной платформы RGB Video Multiprocessing Gateway (VMG). Затем «подготовленные» потоки подаются на сервер RGB TransAct Packager, который выполняет «упаковку» полученных потоков в контейнеры различного формата. TransAct Packager поддерживает выходные форматы Apple HLS, Microsoft Smooth Streaming, Adobe HDS и Adobe RTMP (который не работает поверх протокола НТТР и в данной статье не рассматривается). Потоки, транскодированные с различным битрейтом и «упакованные» в разные контейнеры, передаются затем на CDN сторонних производителей для доставки на клиентские устройства.

RGB-Networks для HTTP-вещания

Рисунок 9

RGB VMG представляет собой специализированную модульную высокопроизводительную платформу для транскодирования потоков. VMG обладает богатыми возможностями по резервированию и большим количеством дополнительных функций (вставка рекламы, наложение изображений и пр.).


Программный продукт TransAct Packager может быть установлен на различные аппаратные платформы, однако компания RGB предоставляет свое аппаратное решение под названием Application Media Server (AMS), конфигурация которого подобрана и оптимизирована для выполнения специализированных задач Packager’а. Также следует отметить, что TransAct Packager может быть интегрирован с DRM-системами ведущих мировых производителей.


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

HTTP-вещание с оборудованием RGB

Рисунок 10

Механизм вставки рекламы при организации вещания поверх протокола HTTP показан на рисунке 10. Сегмент № 7 представляет собой рекламный блок (в реальной ситуации рекламный блок будет состоять из нескольких сегментов). В процессе вещания 2 клиентских устройства получают разные плейлисты, которые содержат ссылки на сегменты рекламных блоков: клиентское устройство № 1 будет воспроизводить исходный рекламный блок (сегмент, расположенный по ссылке «url7»), а клиентское устройство № 2 будет воспроизводить подменный рекламный блок (сегмент, расположенный по ссылке «url7’» на обычном HTTP-сервере).


Решение компании Anevia для организации OTT-услуг


Для организации адаптивного НТТР-вещания компания Anevia предлагает комплексное решение под названием ViaMotion (рисунок 11). Решение позволяет организовать вещание live-потоков и видео файлов на различные клиентские устройства поверх сети интернет. Серверы ViaMotion поддерживают HTTP-вещание с использованием технологий Microsoft Silverlight Smooth Streaming, Apple HTTP Live Streaming, Adobe Flash Video, Google WebM, а также MPEG DASH.

Решение компании Anevia для организации OTTV-услуг

Рисунок 11

Комплексное решение состоит из нескольких серверов и предполагает использование оборудования сторонних производителей (рисунок 12).

Комплексное решение из нескольких серверов

 Рисунок 12

Ключевое место здесь занимает ViaMotion Origin Server, который выполняет прием потоков, «упакованных» в стандартах Smooth Streaming и Apple HLS, формирование нескольких выходных профилей сжатия из одного входного и инкапсуляцию выходных потоков в  контейнеры Smooth Streaming, HLS, HDS, MPEG-DASH и WebM. ViaMotion Origin Server работает с видео кодеком H.264.


В качестве CDN для OTT-услуг компания Anevia предлагает решение под названием ViaMotion Edge Server, который выполняет функции кэширования, резервирования и контроля доступа к контенту.


Для мониторинга услуг OTT предполагается использование сервера ViaMotion Probe, который позволяет выполнять измерения KPI и соответствия параметров услуг договору SLA.


Управление нагрузкой в больших сетях осуществляется с помощью сервера ViaMotion Balancer, который позволяет предотвратить перегрузку внешних каналов и равномерно распределить нагрузку среди всех доступных серверов.
Для контроля доступности услуг используется ViaManager Monitor, который позволяет выполнять мониторинг всех составных частей системы ViaMotion, а также оборудования сторонних производителей.


Как и в предыдущем случае, Anevia ViaMotion Origin Server поддерживает интеграцию с DRM-системами сторонних производителей.


Решение компании Envivio для организации Multiscreen Video Delivery


Для реализации данных задач компания Envivio предлагает решение, состоящее из двух основных компонентов: энкодера Envivio 4Caster C4 Gen III и медиа-процессора Envivio Halo 2 (рисунок 13).

Решение компании Envivio для организации Multiscreen Video Delivery

Рисунок 13

Envivio 4Caster C4 Gen III является высокопроизводительным решением в области энкодирования/транскодирования потоков. Он служит для «подготовки» исходных сигналов и передачи их по опорной сети до пограничных устройств обработки Halo 2, которые выполняют «упаковку» потоков в контейнеры и передачу их на CDN. На данный момент, поддерживаются выходные форматы Apple HLS и Microsoft Smooth Streaming.

Компания Envivio разработала свой формат передачи видео потоков Envivio Genesis™

Рисунок 14

Компания Envivio разработала свой формат передачи видео потоков между энкодерами/транскодерами и медиа-процессорами под названием Envivio Genesis™ (рисунок 14). Вместо того, чтобы передавать по сети один и тот же поток, сжатый с несколькими различными профилями, формат Envivio Genesis™ позволяет передавать один поток максимального качества, который содержит небольшое количество служебной информации, необходимой для получения из него потоков, сжатых с более низкими профилями. Данный подход позволяет значительно снизить нагрузку на транспортные сети и уменьшить тем самым капиталовложения, необходимые для развертывания и эксплуатации сети.

Выводы

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


Однако, к сожалению, на момент написания статьи рынок OTT-услуг в Украине еще не сформировался. Иными словами, компании, реально предлагающие услуги OTT в Украине, можно пересчитать на пальцах, а значительная доля потребителей в нашей стране пока не готова отказаться от традиционных услуг кабельного и вещательного телевидения в пользу OTT. Несмотря на это, в Америке и Западной Европе уже распространено явление, которое получило название «cord-cutting»: наблюдается постепенный отток абонентов цифрового телевидения и IPTV и увеличение доли абонентов OTT-провайдеров.


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

Глоссарий

3GP (формат файлов) – формат мультимедийного контейнера, определяемый Партнёрским Проектом Третьего поколения (англ. Third Generation Partnership Project (3GPP). Является упрощённой версией ISO 14496-1 Media Format, который похож на MOV, используемый QuickTime. Использует видео кодеки MPEG-4 или H.263 и аудио кодеки AMR-NB или AAC-LC.


AAC (Advanced Audio Coding) – патентованный формат сжатия аудио с меньшей потерей качества при кодировании, чем MP3 при одинаковых размерах. Является одним из наиболее качественных форматов, использующих сжатие с потерями, поддерживаемый большинством современного оборудования, в том числе портативного.


CAS (англ. Conditional Access System – Система условного доступа) – программно-аппаратный механизм для ограничения доступа к цифровым телепрограммам.


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


DRM (англ. Digital rights management - Технические средства защиты авторских прав) – программные или программно-аппаратные средства, которые затрудняют создание копий защищаемых произведений (распространяемых в электронной форме), либо позволяют отследить создание таких копий.


H.264 или AVC (англ. Advanced Video Coding) – лицензируемый стандарт сжатия видео, предназначенный для достижения высокой степени сжатия видеопотока при сохранении высокого качества. Описан в документе MPEG-4 Part 10.


HDTV (англ. High-Definition Television – Телевидение высокой чёткости) – телевидение в высоком разрешении. Набор стандартов телевизионного вещания высокого качества, основанных на современных стандартах разложения изображения, значительно превышающих по разрешающей способности телевидение стандартной чёткости, и использующих новейшие цифровые стандарты сжатия цвета и звука.


HTTP (англ. HyperText Transfer Protocol – протокол передачи гипертекста) – протокол прикладного уровня передачи данных. Основой HTTP является технология «клиент-сервер», то есть предполагается существование потребителей (клиентов), которые инициируют соединение и посылают запрос, и поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом.

IP (англ. Internet Protocol) – межсетевой протокол. Относится к маршрутизируемым протоколам сетевого уровня семейства TCP/IP. Объединяет сегменты сети в единую сеть, обеспечивая доставку данных между любыми узлами сети.


IPTV (англ. Internet Protocol Television) – цифровое телевидение в сетях передачи данных по протоколу IP. Доставка контента до клиентского оборудования осуществляется поверх IP-сети оператора.


ISO (англ. International Organization for Standardization – Международная организация по стандартизации) – международная организация, занимающаяся выпуском стандартов.


KPI (англ. Key Performance Indicators) – Ключевые показатели эффективности.


Matroska – проект, нацеленный на создание открытого, гибкого, кроссплатформенного (включая аппаратные платформы) формата мультимедийного контейнера и набора инструментов и библиотек для работы с данными в этом формате. Проект основан на EBML (Extensible Binary Meta Language – расширяемый двоичный метаязык) – двоичном аналоге языка XML. Использование EBML позволяет расширять формат без потери совместимости со старыми программами.


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


MPEG-2 TS (англ. транспортный поток MPEG-2) – протокол передачи аудио и видео данных, описанный в стандарте MPEG-2 Часть 1. Представляет собой формат контейнера, который инкапсулирует пакеты элементарных потоков и других данных.


Multicast (англ. групповая передача) – специальная форма широковещания, при которой сетевой пакет одновременно направляется определённому подмножеству адресатов – не одному (unicast), и не всем (broadcast).


Multiscreen Delivery – вещание одного контента на различные типы оконечных устройств (телевизоры с возможностью подключения к сети интернет, абонентские приставки, компьютеры (в т.ч. планшетные), смартфоны).


OTT (англ. Over-the-Top Television) – доставка видеосигнала на приставку (компьютер, мобильный телефон) пользователя по неуправляемой сети (интернет). Отличается от услуг IPTV тем, что последние предоставляются абонентам через управляемую оператором сеть с гарантированным QoS (QoE).


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

PAT (Program Association Table – Таблица программ) – одна из сервисных  таблиц контейнера MPEG-2 TS, содержит идентификаторы пакетов всех PMT.


PIFF (англ. Protected Interoperable File Format) – формат файлов, который используется для доставки и воспроизведения мультимедийного контента. Спецификации включают описание контейнера, шифрования и метаданных. Используется Microsoft Smooth Streaming.


PMT (англ. Program Map Table – Таблица структуры программ) – одна из сервисных  таблиц контейнера MPEG-2 TS, содержит идентификаторы пакетов и основные характеристики элементарных потоков конкретной программы – видео, звука, дополнительных данных. Для каждой программы есть своя РМТ с собственным идентификатором пакета.


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


SLA (англ. Service Level Agreement – Соглашение об уровне предоставления услуги) – термин, обозначающий формальный договор между заказчиком услуги и её поставщиком, содержащий описание услуги, права и обязанности сторон, а также согласованный уровень качества предоставления данной услуги.


SMPTE (англ. Society of Motion Picture and Television Engineers – Общество инженеров кино и телевидения) – организация, рекомендующая стандарты для кинематографии и телевидения. Разрабатывает стандарты международного значения, выпустила более 400 стандартов, технологических рекомендаций и конструкторской документации по телевидению, кинематографии, цифровому кино, звуку и медицинским изображениям.


UDP (англ. User Datagram Protocol) – протокол пользовательских дейтаграмм. Транспортный протокол для передачи данных в сетях IP без установления соединения. Не подтверждает доставку данных, не заботится о корректном порядке доставки данных и не повторяет отправку.


Unicast – однонаправленная (односторонняя) передача данных, передача пакетов единственному адресату.


URL (англ. Uniform Resource Locator) – Единый указатель ресурсов. Единообразный локатор (определитель местонахождения) ресурса, стандартизированный способ записи адреса ресурса в сети интернет.

VC-1 – видеокодек, изначально разработанный компанией Microsoft. Поддерживается технологиями HD-DVD и Blu-Ray, часто рассматривается как альтернатива H.264.


VoD (англ. Video on Demand – видео по требованию) – видео по запросу, система индивидуальной доставки абоненту телевизионных программ или видеофильмов по кабельной сети с мультимедиасервера.


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


VP8 – видеокодек, созданный компанией On2 Technologies и имеющий открытый исходный код. Исходные коды VP8 открыты под лицензией, схожей с BSD, но дополненной передачей некоторых патентных прав.


XML (англ. eXtensible Markup Language – расширяемый язык разметки) – язык разметки, фактически представляющий собой свод общих синтаксических правил, текстовый формат, предназначенный для хранения структурированных данных и обмена информацией между программами.


Битрейт (англ. bit rate) – скорость прохождения битов информации по каналу связи. Термин битрейт используется в двух основных значениях: 1) характеристика канала или устройства – максимальное количество бит, которое можно передать в единицу времени; 2) величина потока данных, передаваемого в реальном времени (частный случай – битрейт сжатого звука или видео). Выражается битами в секунду (бит/c, bps), а также производными величинами с приставками кило- (кбит/с, kbit/s, kbps), мега- (Мбит/с, Mbit/s, Mbps) и т. д.


Джиттер (англ. jitter – дрожание) – разброс максимального и минимального времени прохождения пакета от среднего значения времени задержки (первая производная задержки прохождения данных по времени).


Контейнер (англ. container) – формат файла или потока, который определяет только способ сохранения данных (а не алгоритм кодирования). Контейнер определяет, сколько данных фактически может быть сохранено, вместе с тем он не определяет способ кодирования самих данных.


Плагин (англ. plug-in) – независимо компилируемый программный модуль, динамически подключаемый к основной программе, предназначенный для расширения и/или использования её возможностей. Плагины обычно выполняются в виде разделяемых библиотек.

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


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


Сеттоп-бокс (англ. Set Top Box, STB) – ресивер цифрового телевидения, устройство, которое принимает сигнал цифрового телевидения, декодирует его, преобразует в стандартный ТВ-сигнал и передает далее на экран телевизора. Ресиверы могут подключаться к спутниковой антенне, к сетям кабельного телевидения, к компьютерным сетям (WiFi, Ethernet) и т. д.


Скремблирование – это обратимое преобразование цифрового потока без изменения скорости передачи с целью получения свойств случайной последовательности («закрытия» контента). После скремблирования появление «1» и «0» в выходной последовательности равновероятны.

Скремблирование – обратимый процесс, то есть исходное сообщение можно восстановить, применив обратный алгоритм.

Транскодирование (англ. Transcoding) – процесс конвертации одного мультимедийного файла (потока) в другой, отличающийся от исходного форматом и/или параметрами потока (например, MPEG-2 -> MPEG-4, MPEG-4 -> MPEG-2, MPEG-2 -> MPEG-2). Транскодирование выполняется устройством под названием транскодер.

Тег (англ. tag) или дескриптор – элемент языка разметки гипертекста. В XML тег является элементом документа, а текст, содержащийся между начальным и конечным тегом – содержанием элемента.

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

Энкодирование (англ. Encoding) – процесс сжатия аналогового цифрового сигнала с использованием определенного кодека (например, MPEG-2, AVC для видео или MPEG-1 Layer 3 для аудио). Выполняется устройством под названием энкодер. Сжатый поток на выходе энкодера имеет гораздый меньший битрейт, чем на входе, что позволяет передавать его по открытым сетям на большие расстояния.

Следите за последними новостями компании DEPS и телекоммуникационного рынка на нашем Telegram канале: Telegram

0 SELECT i.id iid, i.name, i.elements img, i.`publish_up` AS modified, c.id cid FROM `vjprf_zoo_item` i LEFT JOIN `vjprf_zoo_tag`t ON t.`item_id` = i.`id` LEFT JOIN `vjprf_zoo_category_item` ci ON ci.`item_id` = i.`id` LEFT JOIN `vjprf_zoo_category`c ON ci.`category_id`=c.`id` WHERE t.`name` IN ('сеть доставки контента') AND i.`id`<>20491 AND c.id >0 AND i.`type`='article' AND c.`parent` = 152 GROUP BY i.`id` ORDER BY `publish_up` DESC LIMIT 0,3
Похожие материалы
  • Каталог товаров
  • Системная интеграция
  • Сервис-центр
  • Услуги
  • Акции