Маленькие секреты ОТТ

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

Все они целиком вовлечены в бизнес-процесс под названием OTT, который, с одной стороны, крепкими нитями все больше и больше связывает между собой телекоммуникационный и телевизионный мир, и с другой – в то же самое время приближает абонента к производителю продукта под названием “медийный контент” – игры, видеобиблиотеки, телевизионные программы. А вот новичку иногда непросто ухватить суть того или иного названия, прозвучавшего в беседе опытных коллег. Случается, и бывалые специалисты из смежных подразделений далеко не всегда вкладывают одинаковый смысл в названия понятий в процессе переговоров на тему 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 при совокупности следующих факторов:

использование http/tcp вместо rtp/udp, rtsp в качестве протокола доставки информации;
применение нескольких профилей кодирования для каждого сервиса вместо одного;
условно гарантированное качество сервиса в Интернете обеспечено на головной станции за счет механизмов MBR-транскодирования, сегментирования, пакетизации и адаптивности http-потока.

А вот результат внедрения OTT:

сервис доступен вам через Интернет в любой точке мира;
многообразие абонентских устройств от разных производителей: Apple, Android, Microsoft;
снижение требований к гарантированной пропускной способности сети за счет передачи сегментированных потоков данных малых размеров;
относительно низкие издержки на создание транспортной инфраструктуры.

Теперь поговорим про общую ОТТ-инфраструктуру.

На примере блок-схемы, предложенной на рис. 5, расскажем вкратце о сути процесса. Head-End OTT, или головная станция, – первое, что вам потребуется в начале пути. Оригинальный цифровой студийный контент, IPTV-сервисы по своей природе не пригодны для передачи в глобальной сети Интернет, а также для воспроизведения на мобильных смартфонах и фиксированных OTT-приставках. Головная станция выполняет роль преобразователя широковещательной программы в юникаст-потоки, понятные для OTT-приемника. Можно считать, что если у вас есть Head-End, то вы уже готовы предоставить соответствующую услугу абоненту.

Профессиональная головная станция сама создает на выходе не только контент-стримы и манифест-файлы (HLS, SS и так далее), но и соответствующие url-ссылки в качестве адресов, по которым можно получить доступ к желанной телепрограмме, видеоролику и т.д. В системе управления головной станции всегда реализована возможность воспроизведения и мониторинга сформированных на выходе потоков на персональном компьютере и даже вашем личном гаджете путем прямого считывания url-адреса искомого сервиса. В большинстве слу чаев абонент пользуется собственным гаджетом. Ему нужно только подключиться (например, по Wi-Fi) к Интернету и набрать url-адрес в стандартном web-браузере своего гаджета. Сервис-провайдеру остается позаботиться о том, как оповестить абонентов о наличии в его сети сервисов с такими url-адресами.

Маркетологи, умеющие экономить деньги своей компании на этапе пуска, могут найти сравнительно простые способы проинформировать абонентов о наличии услуги и инструментов, о том, как ими воспользоваться. Упростить формат пользования услугой можно при помощи встраиваемого плеера/приложения, загружаемого на гаджет пользователя. Все остальные элементы инфраструктуры сервис-провайдер может “прикручивать” по ходу возникновения желаний, факту необходимости и наличию возможностей

Какое устройство использовать для воспроизведения OTT-сервисов?

Гаджет – абонентское устройство, предназначенное для выполнения авторизации на право доступа к услуге на портале провайдера контента (телеканал, вещатель, частный агрегатор) и, собственно, воспроизведения медиаконтента. Примеры гаджетов – персональный компьютер, iPhone, iPad, семейство смартфонов на платформе Android, Windows Phone, встроенные в STB медиаплееры, PlayStation-приставки. Даже простое перечисление этих устройств наталкивает на мысль, что работают они не совсем одинаково, так как были разработаны разными производителями – Android, Apple, Microsoft и пр. Провайдер OTT-сервиса дает абоненту возможность установить на своем гаджете уникальное приложение/плеер, так называемое клиентское программное обеспечение. При помощи такого “клиента” абонент проходит авторизацию на право пользования услугой и получает очень удобный интерфейс для доступа к нужной ему телепрограмме или материалу из видеобиблиотеки. Плеер представляет собой как бы делегированную на гаджет частичку платформы управления – CMS. В общем случае можно обойтись без “клиента” на гаджете, а для доступа к услуге набирать значение url-ссылки, соответствующей данному сервису в браузере. Это не очень удобно, но зато бесплатно. В крайнем случае компромиссом могут служить так называемые бар-коды. Гаджет просто автоматически считывает бар-код, сформированный на головной станции, и воспроизводит ассоциированную с ним программу. Обычный сотовый телефон, даже смартфон, построенный на операционных системах предыдущего поколения Symbian, Windows Mobile, MeeGo и т.д., не пригоден для воспроизведения OTT-сервисов.

Как гарантировать абоненту условный класс обслуживания, если Интернет – это, по сути, неуправляемая среда для передачи данных?

CDN (content delivery network) – наложенная сеть, состоящая из набора кэширующих серверов. Обещает гарантированную доставку “тяжелого” медийного контента на участке от провайдера услуги до пользователя в условиях использования неконтролируемого канала связи в Интернете. Задача решается за счет репликации больших массивов данных на распределенных узлах и путем конвертации юникаст-сессий в мультикастовые потоки данных. Сеть CDN может быть как частной Off-net CDN, так и построенной оператором широкополосного доступа на базе собственной первичной сети on-net CDN. Теперь понятно, что OTT далеко не всегда обозначает передачу трафика по неуправляемому каналу связи в открытом Интернете.

Три обязательных фактора, вынуждающие задуматься о наличии распределенной CDN-сети, – это сокращение издержек от юникаст-трафика внутри вашей собственной сети передачи данных, лимитированная для HTTP-адаптивного потокового вещания (ABR), величина времени распространения tcp-пакетов между точкой их генерации и приемом на абонентском устройстве и минимизация времени восстановления потерянных/сброшенных tcp-пакетов. Если все эти условия не являются критичными для вашей конкретной системы (обычно так и бывает на первоначальном этапе), то вполне достаточно предусмотреть один централизованный CDN-сервер для ограничения числа одновременных сессий от абонентов, балансировки служебных запросов и трафика с разных направлений, реализации функций прокси-сервера в направлении вашей головной станции. Если вы построили или арендовали CDN, но не в состоянии предложить своим абонентам оформить контрактное соглашение на предоставление OTT-сервисов с учетом гарантированного качества и класса обслуживания, то деньги вы потратили зря.

Как объединить внутренние рабочие процессы между всеми элементами системы?

CMS/Web-portal (Content management system and web portal) – система управления контентом – используется для:

авторизации клиентов на право предоставления услуги;
контроля доступа к разным типам контента;
автоматической загрузки рекомендованного плеера на абонентский гаджет;
отправки url-адреса, запрошенного сервиса на абонентский плеер;
автоматизации процессов публикации контента на web-портале платформы;
управления процессом движения VoD-, Time Shift контента внутри головной станции;
загрузки метаданных программы передач телеканалов и VOD-фильмов;
управления включением рекламных роликов;
автоматической замены контента внутри юникаст-группы по меткам и расписанию;
планирования задач отложенного просмотра;
сбора информации об активности абонентов;
взаимодействия с биллинговой системой;
создания системы оповещения ГОЧС;
составления отчетов для правообладателей о потреблении контента.

Эти и многие другие “фишки”, любимые маркетологами, могут быть реализованы на базе CMS-платформы в качестве функций, полезных для продвижения услуги на рынок. Имеет смысл ориентироваться на модульные платформы, которые разрешают добавлять каждую функцию по отдельности в соответствии с вашими желаниями и потребностями.

Как защитить контент от попыток несанкционированного доступа?

Здесь все как обычно. DRM выполняет генерацию ключей для шифрования, как файлов, так и телепрограмм. Само по себе скремблирование контента происходит на пакетайзере внутри головной станции. Устройства DRM и пакетайзер общаются между собой на известном им обоим языке путем обмена служебными сообщениями. Различают несколько алгоритмов криптования Play ready DRM /AES-CTR (Smooth и HLS), AES-128-CBC (HLS), Adobe Access (HDS), CENC (DASH). Сейчас наибольшее распространение получил AES-128-CBC. Все популярнее становится Play Ready, где данные хранятся на гаджете в зашифрованном виде и могут быть воспроизведены только через назначенный ранее интерфейс, например HDMI. Мультимедийные файлы, содержащие сегменты потока, могут быть зашифрованы на пакетайзере одним из указанных протоколов. Головная станция публикует ссылки на ключи дешифрации в виде url-адреса внутри плейлиста. Кстати, оборудование головной станции может самостоятельно генерировать кодовые ключи и выполнять шифрование без использования дорогостоящей DRM-системы. Согласитесь, достаточно оправданный выбор на начальном этапе развития услуги.

Перечисленные выше Head-End, CMS, DRM, CDN и клиентское приложение на гаджете можно в целом расценивать в качестве пяти фундаментальных элементов OTT-инфраструктуры. На момент написания этой статьи не существует ни одного производителя в мире, у которого все они были бы своими. Почему? Да потому, что производителю нет никакого смысла заниматься всерьез и инвестировать в непрофильные для себя активы. Поэтому если вы приступаете к выбору решения, то полагайтесь не только на посторонние обещания, но и на свои знания, проверенные бренды, потрудитесь обратить внимание на уже существующие аналогичные проекты, успешно реализованные этим поставщиком оборудования в комплексе с партнерами. В серьезной компании не будут скрывать своих технологических партнеров, включая список услуг и приложений, которые были ранее успешно интегрированы. В зависимости от предполагаемой услуги и роли конкретного игрока в бизнес-процессе можно отказаться от части этого списка, но только Head-End будет обязательной составляющей в любом случае. Самостоятельно провести интеграцию всего комплекса и проверку его работоспособности довольно сложно по целому ряду причин – это и необходимость иметь квалифицированных специалистов в телевидении, телекоме и программировании, и затрата свого времени и денег на эти процедуры. Поэтому иногда лучше довериться профессионалам, которые могут выполнить весь объем необходимых мероприятий. К тому же сейчас таких компаний становится все больше. Казалось бы, дело сделано – и вы, имея в своем распоряжении понимание обо всех элементах, на мажорной ноте, важной походкой вступаете в почетный ряд OTT-сервис-провайдеров. Но это заблуждение…