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

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

24 січня 2016

Перегляд телевізійних програм на планшетному комп'ютері або смартфоні вже не є чимось незвичайним і екзотичним, так само, як недавно увійшло в наше життя 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

 555555555555555555555555555555555555555555555555555555555555555555555555555555

<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" < br/> MaxHeight="180" FourCC="H264" NALUnitLengthField="4"/​​>
< QualityLevel Index="1" Bitrate="500000"
CodecPrivateData="00000001274D401F9A628343F6022000007D20001D4C12800000000128EE3880" MaxWidth="416" < br/> MaxHeight="240" FourCC="H264" NALUnitLengthField="4"/​​>
< QualityLevel Index="2" Bitrate="750000"
CodecPrivateData="00000001274D401F9A6281405FF2E022000007D20001D4C1280000000128EE3880" MaxWidth="640" < br/> MaxHeight="360" FourCC="H264" NALUnitLengthField="4"/​​>
< QualityLevel Index="3" Bitrate="1000000"
CodecPrivateData="00000001274D401F9A6281405FF2E022000007D20001D4C1280000000128EE3880" MaxWidth="640" < br/> MaxHeight="360" FourCC="H264" NALUnitLengthField="4"/​​>
< QualityLevel Index="4" Bitrate="1250000"
CodecPrivateData="00000001274D40289A6281B07FF36022000007D20001D4C1280000000128EE3880" MaxWidth="864" < br/> MaxHeight="486" FourCC="H264" NALUnitLengthField="4"/​​>
< QualityLevel Index="5" Bitrate="1500000"
CodecPrivateData="00000001274D40289A6281E022FDE022000007D20001D4C1280000000128EE3880" MaxWidth="960" < br/> MaxHeight="540" FourCC="H264" NALUnitLengthField="4"/​​>
< QualityLevel Index="6" Bitrate="3000000"
CodecPrivateData="00000001274D40289A6280A00B76022000007D20001D4C12800000000128EE3880" MaxWidth="1280" < br/> 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"/>
< ct="2489580588333" d="21354667"/>

< 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="31 466" CodecPrivateData="1 190" SamplingRate="48000" Channels="2"
BitsPerSample="16" PacketSize="4" AudioTag="255" FourCC="AACL"/>
< QualityLevel Index="1" Bitrate="31 469" CodecPrivateData="1190" SamplingRate="48000" Channels="2"
BitsPerSample="16" PacketSize="4" AudioTag="255" FourCC="AACL"/>
< QualityLevel Index="2" Bitrate="31472" CodecPrivateData="1 190" SamplingRate="48000" Channels="2"
BitsPerSample="16" PacketSize="4" AudioTag="255" FourCC="AACL"/>
< QualityLevel Index="3" Bitrate="31482" CodecPrivateData="1 190" 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"/>
< ct="2489578962444" d="21333334"/>

Малюнок 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 і WaltDisney є противниками розробки та впровадження 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`<>63015 AND c.id >0 AND i.`type`='article' AND c.`parent` = 7169 GROUP BY i.`id` ORDER BY `publish_up` DESC LIMIT 0,3
Схожі матеріали
  • Каталог товарів
  • Системна інтеграція
  • Сервіс-центр
  • Послуги
  • Акції