В рубрику "Оборудование и технологии" | К списку рубрик | К списку авторов | К списку публикаций
Все они целиком вовлечены в бизнес-процесс под названием OTT, который, с одной стороны, крепкими нитями все больше и больше связывает между собой телекоммуникационный и телевизионный мир, и с другой – в то же самое время приближает абонента к производителю продукта под названием “медийный контент” – игры, видеобиблиотеки, телевизионные программы. А вот новичку иногда непросто ухватить суть того или иного названия, прозвучавшего в беседе опытных коллег. Случается, и бывалые специалисты из смежных подразделений далеко не всегда вкладывают одинаковый смысл в названия понятий в процессе переговоров на тему OTT. Справедливости ради стоит отметить факт скудного количества методического материала, посвященного этой теме, особенно в русскоязычной литературе. В процессе прочтения статьи внимательный читатель быстро поймет, почему я выбрал для нее такое название. В дальнейшем эти маленькие секреты станут нашими большими друзьями. Мы избежим многих конфузных ситуаций на этом поле в будущем, если сможем правильно интерпретировать понятия и термины, прячущиеся за латинскими аббревиатурами. Договоримся об одинаковой трактовке понятий ОТТ-инфраструктуры и будем придерживаться правил как минимум в рамках локальной беседы.
Так в чем же отличие OTT от традиционного IPTV, и WebTV в частности? Ответ прост только на первый взгляд: разница между ними в обработкe медиаданных на головной станции провайдера и абонентском устройстве, а также в способе транспортировки данных в сети, хотя и используют они интернет-протокол (IP).
IPTV (internet protocol television) – сеть c пакетной коммутацией, в которой телевизионные сервисы формируются и передаются на базе стека протоколов TCP/IP (RTP, UDP, IP, IGMP, маршрутизации, ICMP, RTSP и ряда других). Поставщик услуги использует собственную сетевую инфраструктуру для доставки видео на участке между принадлежащей ему станцией подготовки контента до абонентов. Сеть доставки IPTV замкнута в определенных границах и находится под контролем поставщика услуги, который гарантирует абоненту уровень надежности и качество обслуживания за счет управления пропускной способностью сетевых ресурсов. Для распространения сигнала используется технология IP-мультикаст, в которой пакет данных передается заданному (обычно более чем одному, но не всем) количеству адресатов. Видео оправляется абонентам, сделавшим запрос на подключение к мультикастовой группе, которая всегда присутствует в сети. В качестве транспортного протокола при этом используется UDP (RTP).
Под термином WeB TВ обычно понимают передачу любого видеофайла в Интернете от сервера к клиенту. При предоставлении услуг WeB TВ используются те же протоколы, что и в IPTV, но механизм распространения отличается – вещание допускается как в неконтролируемой сети Интернет, так и в закрытом интранет-кластере по схеме “точка-точка” после обращения абонента за сервисом. Существующие на Web-сервере поставщика услуг индивидуальные медиафайлы загружаются на компьютер по запросу через встроенный в Web-браузер плеер (Windows Media Player или RealPlayer) и становятся доступны для просмотра после того, как файл сохранен на компьютере полностью (или частично). Это классический способ, названный прогрессивной загрузкой (progressive downloads). Практическое применение – это перекачка клипов маленьких размеров.
Для создания WebTV-трансляций в режиме реального времени, а также загрузки клипов больших размеров, на Web-сервере устанавливают специализированное приложение потокового вещания. За передачу потоковых данных отвечает транспортный протокол реального времени RTP (IETF/RFC 3550). На участке “клиент-сервер” между соответствующими портами устанавливается юникаст RTP-сессия для передачи медиаданных. Клип фрагментируется и передается отдельными частями. Управление трансляцией осуществляется по протоколу RTSP (IETF/RFC 2326). Адрес для воспроизведения сервиса может быть таким: rtsp://x.x.x.x/directory/file-name.rm. Хороший пример потокового WebTV-вещания – это система, реализованная на базе Adobe Flash media (или Wowza) сервер и rtmp-протокола. Практическое применение – это линейное телевидение или видео по запросу обычно внутри отдельно взятой сети оператора связи.
OTT (Over-the-Top) – этот термин в отрасли связи определяет бизнес-модель с возможностью доставки медийного видеоконтента в виде совокупного набора любых телевизионных услуг через неуправляемую сеть Интернет на устройство пользователя без ограничения в принадлежности абонента к оператору связи. Для пересылки медиаконтента между источником и получателем используется HTTP- (TCP) протокол, выполняющий транспортировку данных, видео- и аудиотрафика от провайдера до потребителя в любой точке земного шара. Как только у абонента появляется доступ в Интернет, он сразу может считать себя частью мира OTT и стать подписчиком у множества соответствующих провайдеров телевизионных, игровых и развлекательных сервисов. Технология широкополосного доступа, использованная для подключения абонента внутри локальной операторской сети, не имеет принципиального значения. Оператор широкополосного доступа может быть в курсе содержимого IP-пакетов, но не в состоянии управлять потоком данных, влиять на содержимое контента на свое усмотрение и не несет ответственности перед абонентом за качество сервиса.
Для описания рабочего процесса для OTT-модели в обиход были введены следующие определения:
1. Http live streaming (потоковое http-вещание). На сервере провайдера медиаконтент представлен в виде набора потоков, нарезанных на файлы маленьких размеров (чанки). Абонентский плеер контролирует прием отдельных сегментов видеопотока/файла и выполняет их соединение друг с другом в правильной последовательности. Для транспортировки данных и обмена контрольными сообщениями между сервером и клиентом используются стандартные операции http-протокола. Передача в форме http live streaming пройдет через любой брандмауер или прокси-сервер, не будет заблокирована маршрутизатором и не потребует открытия специальных портов дополнительно к тем, которые активны по умолчанию в любом интернет-кластере, в отличие от RTP/UDP-ориентированных сессий, присущих IPTV и WeB TV. Видео становится доступным для воспроизведения непосредственно по мере поступления отдельных чанков контента на абонентский гаджет, без предварительной полной загрузки всего файла.
Теперь перечислим технологические процессы, необходимые при подготовке контента в соответствии с требованиями, предъявляемыми к качеству предлагаемой OTT-услуги.
2. Single bit rate (SBR) – один профиль с заданным битрейтом кодирования видео и аудио для входного источника сигнала. Как минимум оригинальный контент нужно перевести в цифровой компрессированный формат (рис. 2).
3. Multi bit rate (MBR): несколько синхронизированных между собой профилей с заданным битрейтом кодирования видео и аудио в каждом из них для входного сигнала (рис. 3).
Обратите особое внимание на возможность гибкой настойки параметров кодирования/транскодирования для видео и аудио внутри профилей. В дальнейшем вы избавите себя от многих хлопот и повторных издержек, если ваш выбор будет сделан в пользу оборудования, у которого предусмотрен путь программного перехода к кодеку HEVC (H.265). При выборе оборудования остерегайтесь софтовых решений, которые используют низкоэффективные однопроходные способы кодирования без предсказания или, хуже того, могут не поддерживать часть профилей, уровней, фильтров согласно определению стандарта. Они часто грешат манипуляциями с внутренними параметрами кодека с целью повышения производительности устройства в программной реализации в ущерб качеству кодирования при заданном битрейте. Ваши абоненты вряд ли заслуживают такого отношения. Отдать предпочтение имеет смысл профессиональному кодеру, у которого есть возможность гибко управлять видео/аудиопрофилями и уровнями, битрейтом, разрешением, длиной и структурой GOP, частотой следования IDR-кадров.
4. Average bit rate (AvBR): опция включения статистического усреднения скорости передачи данных выходного транспортного потока, наличие которой не помешает в шорт-листе желанных функций. Механизм AvBR представляет собой нечто среднее между CBR и VBR. Он позволяет повысить качественное восприятие услуги (скорость преключения между программами) и прогнозировать мгновенную загрузку сетевых ресурсов в сравнении с VBR-режимом. C другой стороны, при включении AvBR в транспортный поток добавляются null-пакеты, но в достаточно меньшей степени, чем для CBR, что в итоге снижает издержки на http-сети в сравнении с CBR-режимом за счет сокращения передачи числа контейнеров, не имеющих полезной нагрузки. Для плеера противопоказано иметь в своем буфере чанки только с null-пакетами, он будет их сбрасывать и запрашивать новые пакеты с актуальными данными.
5. Play list/Manifest: если у вас есть закодированные MBR-потоки, то вы следующим шагом сегментируете их на короткие медиафрагменты одинаковой длины (обычно 5–10) и создаете плейлист/манифест-файл. Плейлист представляет собой список правил, согласно которым плеер собирает медиа-фрагменты, а затем воспроизводит их как единый сюжет.
Широко использующиеся сегодня протоколы адаптивного потокового вещания классифицируются по принадлежности к их создателям: HLS (Apple), Smooth Streaming (Microsoft), HDS (Adobe). Обычно абонентское устройство принимает и обрабатывает один из этих протоколов, но в ряде случаев можно установить несколько плееров для поддержки разных форматов.
Для HLS-протокола MBR-видео/аудиопотоки сегментируются на чанки в mpeg2.ts, H.264 видеокодек и AAC аудиокодек. Мастер-плейлист перечисляет доступные индивидуальные плей-листы (индексные файлы) альтернативных профилей одного и того же контента с различными скоростями передачи для устройств с разным экранным разрешением. Индивидуальный плейлист обеспечивает упорядоченный список URL-адресов для сегментов медиафайлов и показывает детали кодирования в выбранном профиле, чтобы плеер выбирал совместимые потоки. Файлы плейлистов имеют формат .M3U8. Мастер-плейлист загружается плеером только один раз, а индексные файлы перезагружаются периодически для линейных трансляций.
MSS (Microsoft Smooth Streaming) использует PIFF-контейнер (Protected Interoperable File Format) в формате F-MP4, H.264 видеокодек и AAC аудиокодек. В качестве плей-листа используется XML-файл (манифест), который содержит информацию о фрагментированных потоках и альтернативных профилях. Клиенту не нужно многократно скачивать манифест-файл, так как URL-адреса чанков вычисляются непосредственно в каждом профиле.
HDS использует стандартный F-MP4-формат, H.264 видеокодек и AAC аудиокодек. В качестве мастер-плейлиста выступает XML-манифест-файл, который содержит информацию о доступных профайлах. Обновляемый Bootstrap-файл двоичного формата позволяет плееру получать URL-адреса для загрузки доступных медиасегментов.
Сегментированные медиапотоки, а также плейлисты загружаются на HTTP-сервер, который, в свою очередь, переправляет их на абонентское устройство. Для любого из перечисленных протоколов на участке “сервер – клиент” устанавливается HTTP юникаст-сессия для передачи медиаданных.
6. Adaptive bitrate Streaming, ABR (адаптивное потоковое вещание): технические параметры сеанса связи между Web-сервером OTT-провайдера и клиентским устройством умеют приспосабливаться к доступной в данный момент скорости передачи данных, задержкам и т.д. в канале связи. На гаджете абонента выполняется автоматическая подстройка воспроизведения онлайн-трансляции в зависимости от состояния соединения с сервером. По мере того как подходит к концу воспроизведение текущего сегмента элементарного потока данных, абонентский плеер выбирает новый сегмент из числа альтернативных потоков (помните, мы кодировали источник в несколько MBR-профилей). Все потоки содержат одинаковый видеоматериал, то есть представляют собой несколько связанных друг с другом профилей кодирования, но с различными скоростями и разрешениями.
Термины HTTP Live streaming и Adaptive bitrate streaming дополняют друг друга при объяснении механизма распространения информационных потоков в OTT-модели. Абонентское устройство контролирует параметры канала связи, анализируя поступающие данные, а результаты отправляются обратно в направлении сервера. Фактически абонент сигнализирует серверу о своем выборе оптимального для воспроизведения на данный момент профиля (вот почему адаптивное) в зависимости от мгновенно “предсказанной” доступной полосы пропускания, задержки, загруженности процессора, размера своего буфера памяти, поддерживаемого экранного разрешения и т.д. с целью получения максимально доступного качества изображения.
В заключение скажу, что еще несколько лет назад OTT мне казался просто маркетинговым термином. Однако практический опыт работы в реальных проектах помог увидеть технические нюансы, которые отличают OTT от IPTV/WeB ТВ ориентированных реализаций. Вы точно имеете дело с OTT при совокупности следующих факторов:
А вот результат внедрения OTT:
В следующих номерах журнала поговорим подробно про общую OTT-инфраструктуру, состав оборудования головной станции, классификацию видеосервисов, современные стандарты 4K/UHD и HEVC, DASH и монетизацию услуг.
Опубликовано: Журнал "Broadcasting. Телевидение и радиовещание" #4+5, 2014
Посещений: 25130
Автор
| |||
В рубрику "Оборудование и технологии" | К списку рубрик | К списку авторов | К списку публикаций
