В результате появилась комплексная система Adobe, использующая корпоративный протокол RTMP Real Time Messaging Protocol и платформу Flash, разработанную для создания и воспроизведения мультимедиа. Эта система хорошо справлялась с задачами стриминга. Применение специализированого протокола обмена между сервером и клиентом обеспечивало и минимальные задержки при передаче, и оптимальную загрузку транспортного канала. Однако у системы были серьезные недостатки — высокая стоимость и сложность в реализации. В частности, закрытость протокола и требование постоянного соединения с серверов создавали проблемы с обходом брандмауеров, вставкой рекламы и неоправданно загружали приемник. Flash-плееры, требующие языка Java, при своей высокой функциональности тоже были достаточно тяжелыми для приемников семи-, восьмилетней давности. Но за неимением решений, конкурирующих по функционалу, RTMP + Flash долго были лидерами рынка.
HTTP-стриминг и распространение HLS
В ответ на проблемы этой системы начали появляться решения для стриминга, работающие на базе стандартного HTTP-протокола. Исходно он разрабатывался для передачи гипертекста, но в 1998 году вышла версия HTTP 1.1 с двумя важными усовершенствованиями, позволившими резко сократить время ответа. Первое — была добавлена возможность отправки множества запросов в рамках одной сессии TCP/IP, второе — появилась возможность отправлять несколько запросов, не дожидаясь предыдущего ответа. Это сделало стриминг через HTTP реальной затеей.
В HTTP-системах клиентское устройство получает видео сегментами, отправляемыми в ответ на HTTP-запросы. Размер одного сегмента обычно колеблется от 2 до 10 сек. Первые версии технологий HTTP-стриминга были неадаптивными, то есть клиентcкое устройство оценивало состояние канала только при начальном обмене с сервером и запрашивало определенную скорость передачи из списка вариантов, присланных ему сервером в манифест-файле (файле с описанием услуги). Однако довольно быстро в HTTP-системах появилась адаптивность. Раз в несколько сегментов клиентское устройство проверяет соответствие выбранного профиля и текущего состояния канала и при необходимости запрашивает другой профиль.
Как и любое направление, ОТТ первоначально развивалось на базе корпоративных протоколов. Первое время на слуху были три технологии на базе HTTP: Adobe Real Rime Messaging Protocol (RTMP), Microsoft Smooth Streaming (MSS), Apple HTTP Live Streaming (HLS), и Adobe HTTP Dynamic Streaming (HDS). Но постепенно индустрия сделала выбор в пользу одного из них, а именно HLS от Apple. По единодушному мнению специалистов, HLS не самый функциональный вариант из перечисленных. Однако у него есть и существенные преимущества. Во-первых, это стандарт с открытым кодом, то есть сам по себе безлицензионный, хотя за использование интегрированных в него MPEG-технологий платить все-таки приходится. Во-вторых, он прост в реализации и, как все разработки Apple, был хорошо отработан, интегрирован с продуктами компании и встроен в ОТТ-инфраструктуру. В результате HLS почти монополизировал рынок ОТТ и сейчас HLS и OTT воспринимаются практически как синонимы. Тем не менее монопольное положение HLS уже нарушено появлением на рынке MPEG-DASH.
MPEG-DASH
В отличие от остальных HTTP-технологий MPEG-DASH — общеиндустриальный стандарт, ратифицированный ISO/IEC MPEG. В его разработке принимали участие многие крупные компании, в том числе Adobe и Microsoft, имеющие собственные HTTP-решения.
В результате разработчики реализовали там максимальное количество своих пожеланий и в стандарт попал весь функционал корпоративных платформ решений, а также многое из того, чего в них нет. Исчерпывающее сравнение функционала HTTP-платформ можно найти на сайте Bitmovin, а мы ограничимся перечислением возможностей MPEG-DASH, отсутствующих в HLS или отсутствовавших в нем на момент разработки DASH.
Возможности DASH
Одним из преимуществ DASH по сравнению с HLS является поддержка multi-DRM. Она заключается в том, что в манифест-файле DASH предусмотрена возможность включения информации о нескольких используемых DRM и адресах серверов, к которым можно обратиться для получения лицензии на просмотр.
Структура MPEG-DASH построена таким образом, что не зависит от форматов компрессии передаваемых видео- и аудиопотоков. Это позволяет легко добавлять новые форматы в стриминговые сервисы. В него было заложено несколько транспортных контейнеров, в том числе фрагментированные MP-4-файлы (fMP-4). Они отличаются от MPEG-2 TS (единственного на тот момент контейнера в HLS) более компактным заголовком, а главное, понимаются HTML-5 — языком представления интернет-данных с поддержкой мультимедиа. В первом приближении, HTML-5 предназначен выполнять задачи, схожие с Flash. Лет шесть назад консорциум W3C утвердил два расширения, необходимых для работы браузерных плееров на базе HTML-5.
MSE (Media Source Extention) позволяет Java Script работать с потоками видео и аудио в среде HTML-5 — анализировать манифест-файлы, переключать потоки с разными битрейтами, подгружать файлы и передавать видео для проигрывания встроенному в браузер HTML-5-плееру.
EME (Encrypted Media Extention), позволяет JavaScript работать с системами DRM для расшифровки контента.
Интеграция в браузеры этих расширений исключила необходимость создания приложений для каждого типа абонентских устройств, поэтому их появление трудно переоценить. Строго говоря, расширения не привязаны к MPEG-DASH, но они были необходимы для его распространения.
Вернемся к функционалу MPEG-DASH. В стандарт заложен ряд функций, оптимизирующих работу операторской сети. В частности, сигнализация, позволяющая клиентскому ПО выбирать лучшие варианты, если поток может быть доставлен ему по разным CDN, а также разнообразные сервисные возможности типа метрик качества, мониторинга активностей клиента и встроенных функций нелинейного воспроизведения.
Обратной стороной гибкости и высокой функциональности стандарта оказалась его громоздкость. И хотя его первый релиз появился почти восемь лет назад, ранние реализации DASH-плееров были усеченными, причем разные разработчики усекали его по-разному. Это затормозило распространение MPEG-DASH, тем более что на первых этапах не был готов и пакет стандартов для браузерного воспроизведения медиа.
Последние несколько лет стандарт активно завоевывает позиции. Он поддерживается основными браузерами: Google Chrome, Internet Explorer, Firefox, Safari и используется такими крупными провайдерами, как, например, Netflix, Youtube, Hulu и Comcast. Он также поддерживается HbbTV начиная с версии 1.5 и интегрирован с системой цифрового эфирного телевидения ATSC3.0.
HDS от Adobe активно заменяется на DASH, то же самое происходит с MSS от Microsoft. Однако HLS, самый распространенный корпоративный стандарт, свои позиции сдавать не собирается. Как минимум ближайшие пять лет ожидается сосуществование этих двух технологий, а в долгосрочной перспективе многое будет зависеть от готовности Apple поддерживать и развивать технологию.
MPEG-DASH и HLS — проблемы совместимости
Так как все большее количество провайдеров вещают в обоих стандартах, три года назад была сделана попытка исключить дублирующие передачи. Это позволило бы значительно сэкономить транспортные ресурсы, облегчить работу CDN и самих сервис-провайдеров. Для этого формат FMP4 был включен в качестве одного из контейнеров в спецификацию HLS и одновременно стандартизирован в качестве контейнера в стандарте MPEG Common Media Application Format (CMAF), о котором поговорим ниже. Предполагалось, что теперь транспортные форматы будут различаться только метаданными (манифест-файлом в MPEG-DASH и плей-листом в HLS) и операторы, поддерживающие обе технологии, смогут распространять единый поток видеоконтейнеров. Однако разработчики HLS и DASH пока не смогли договориться об использовании общего алгоритма скремблирования видео. В результате сегодня существует два варианта Common Encription, один из них используется с DRM PlayReady и WideWine и другими DRM, а второй — с FairPlay от Apple. Поэтому пока общие транспортные потоки можно создавать только для открытого контента. Кроме того, множество HLS-проектов уже запущено и работают с контейнерами MPEG-2 TS и пока не видят для себя резона переводить их на FMP4.
ОТТ и мультикаст
При появлении стриминговых технологий многим казалось, что препятствием для массового применения станет их юникастовая природа, то есть плохое масштабирование. Действительно, нагружать серверы и сеть одного и того же потока тысячами пользователей одновременно кажется неперспективным занятием.
Строго говоря, HTTP не привязан к определенным протоколам низкого уровня и может работать в связке с мультикастом на базе IGMP. Однако к этому есть другие препятствия. В мультикастовой технологии не заложены механизмы обеспечения надежности передачи и преодоления заторов, нет защиты от атак разного вида и т. д. В закрытых администрируемых сетях эти проблемы решаются расчетом пропускной способности каналов и дополнительными механизмами защиты, а в открытой сети эту надстройку надо было бы создавать.
Кроме того, мультикаст поддерживают не все интернет-маршрутизаторы. Конечно, эта проблема тоже решаемая: уже давно существует механизм транзитной передачи мультикастовых потоков через области Интернета без поддержки мультикаста — Automatic Multicast Tunneling (AMT). Однако внедрять эту технологию должны были бы операторы, которые часто не заинтересованы вкладывать средства в модернизацию своей сети.
На самом деле проблема оказалась не столь глобальной, так как задачу оптимального распространения контента взяли на себя CDN-сети, в которых используются свои сложные алгоритмы раздачи на кэширующие серверы. В зависимости от размера CDN и топологии сети кэширующих серверов используется и FTP, и MFTP (пиринговая разновидность FTP), и варианты мультикаста, реализуемого на прикладном уровне Application Layer Multicast (ALM). Разветвленная сеть CDN позволяет минимизировать дополнительные транспортные затраты на юникастовый стриминг и экономить транспортный ресурс при доставке VOD.
Новый вариант ABR
Другое направление оптимизации загрузки — ABR. Два-три года назад крупнейшие разработчики кодеров, такие как Harmonic, Cisco и Ericsson, представили индустрии кодеры ABR (Adaptive Bit Rate), формирующие профили видео, где постоянная скорость потока заменяется постоянным качеством видео. Выигрыш от такого решения в том, что высокое качество картинки не всегда требует максимальной скорости передачи, — оптимизируется использование транспортного ресурса канала, а пользователь может чаще получать видео верхнего профиля.
Такой подход требует более интеллектуальных кодеров и технологий оценки качества картинки. В кодерах Harmonic применяется корпоративная технология поддержки стабильного качества картинки EyeQ, а в других решениях используются стандартные методы оценки качества.
Пути снижения задержки
Она из самых больных проблем HTTP-стриминга — большие задержки от момента съемки до появления контента на экране. В системе Adobe RTMP/Flash при достаточных транспортных ресурсах задержка составляет 2-3 секунды, что даже меньше стандартных 5—10 сек для вещательного канала. В системах на базе HTTP задержка составляет от 20 до 60 секунд, а иногда и больше. Причина такой задержки — последовательная обработка сегментов каждым элементом цепочки. А элементов достаточно много: система предварительной обработки видео, кодер, пакетизатор, сервер-источник, один или несколько кэширующих серверов CDN, граничный сервер СDN — сеть доступа, буфер клиентского устройства. Каждый элемент вносит задержку, равную времени обработки одного сегмента и результаты суммируются. Какие-то потоки могут быть сохранены на кэширующих серверах, тогда фактическая задержка окажется меньше, но так как задержка может меняться, например, при переходе от одного профиля видео к другому, то система все равно работает с максимальной задержкой. Эта проблема особенно заметна в HLS-стриминге, где стандартный размер сегмента составляет 10 секунд. Причем плееры в устройствах Apple начинают проигрывание после того, как в их буфере накопится три сегмента, то есть 30 секунд видео. Эта мера связана в основном с неустойчивым состоянием интернет-каналов, а большая длина одного сегмента — еще и со стремлением снизить долю заголовка в общем объеме.
С развитием CDN и общим увеличением пропускной способности каналов такой запас стал избыточным, а появление стандарта CMAF c эффективным контейнером позволило сократить размер сегмента. На самом деле CMAF не ограничивается определением контейнера, но также описывает порядок пакетизации, в том числе объединения и синхронизации разные версий потока. Среди прочего в нем предусмотрена возможность выделения маленьких подсегментов (чанков) в рамках одного сегмента. Это обстоятельство используется при реализации режима передачи с низкой задержкой, позволяющего, по оценкам специалистов, снизить ее до 3 секунд.
Снижению задержки будет также способствовать массовый переход на стандарт HTTP 2.0, принятый в 2015 году. Он разрабатывался в том числе и с учетом задач медиастриминга, и по сравнению с нынешней версией HTTP 1.1 в нем много полезных для стриминга усовершенствований. Он, в частности, позволяет приоритизировать запросы, более гибко разбивать ответы на фрагменты и даже отправлять с сервера данные, которые еще не были запрошены клиентом. К тому же заголовки сообщений в этом протоколе отправляются в компрессированном виде и занимают меньше места.
B2B-стриминг
Стриминговые технологии применяются не только для доставки видео конечным пользователям, но и для профессиональной передачи. Если речь идет о доставке в точки ретрансляции, то это часто решается с помощью CDN, иногда даже на базе традиционного HLS. По информации от Cisco, некоторые операторы используют HLS для доставки видео к сегментам администрируемых сетей IPTV, заменяя ими прежние транспортные решения. Логика такого подхода заключается в том, что HLS-формат все равно требуется для доставки на гаджеты, и чтобы не дублировать транспортные потоки и не поддерживать две системы доставки, операторы оставляют только стриминг. Помимо доставки в точки ретрансляции, существуют задачи передачи живого контента с места события до студии и межстудийная передача или раздача корпоративного видео. Кроме того, некоторых могут не устраивать условия или технические возможности доступных CDN. Другими словами, транспортные системы, не интегрированные с CDN, тоже имеют право на жизнь.
Самое известное транспортное решение для B2B-сектора — Nimbra Appliance шведской компании Netinsight. О нем известно только, что оно позиционируется как замена выделенной линии, не уступающее по надежности, скорости и безопасности передачи, и включает собственные кодеры и декодеры.
Еще одно интересное решение — QARVA MultiPipe, оно разработано грузинской компанией QARVA. Оно позволяет передавать видео по кусочкам с разных серверов и собирать их воедино на клиентском устройстве. По всей видимости, это торрент-технология, хотя разработчики не используют этот термин, вероятно, из-за стойких ассоциаций с пиратством. В то же время торрент-технология совершенно не обязательно предполагает пиратское использование. Аналогичное решение в свое время предложила компания Ocotoshape, позже купленная крупнейшей CDN-сетью Akamai. Решение QARVA MultiPipe как раз позволяет обойтись без услуг CDN. Кроме того, видео делится на очень маленькие фрагменты, что позволяет избежать задержек при начале просмотра или переключении на другой канал. Опыты подтвердили, что эта технология позволяет без задержек передавать по открытому Интернету даже 4К-каналы. Разработчик позиционирует это решение как B2C, и его можно так использовать в сети со специализированными приставками. Однако для стриминга на стандартные гаджеты его можно использовать как замену CDN.
Отдельно можно рассматривать задачу переброски потока из одной точки в другую. Для ее решения предлагается протокол SRT (Secure Reliable Transport), разработанный компанией Haivision. Эта компания специализируется в основном на разработке кодеров, транскодеров и декодеров, в которые и были интегрированы первые версии SRT. Этот алгоритм имеет встроенный механизм восстановления потерянных пакетов, постоянно мониторит состояние канала и адаптирует к нему передаваемый поток, а также защищает видео AES-шифрованием. По сути, он делает то же, что и другие протоколы для передачи видео через открытый Интернет с непредсказуемым качеством каналов. Статус индустриального стандарта SRT получил благодаря тому, что весной 2017 года был основан SRT-альянс, а сам протокол был выложен в открытый доступ. Вначале в состав альянса входило всего две компании — Haivision и Wowsa Media Solutions. Однако потребность в открытом решении такого рода была настолько велика, что за следующий год альянс набрал более 100 участников, и их число продолжает расти. Среди них такие известные нам компании, как Harmonic, Appear TV, WISI и Sencore. На выставке IBC 2019 на стендах большинства этих компаний можно было видеть кодеры с поддержкой SRT. Более того, есть уже десятки внедрений этого протокола в действующих проектах.
Заключение
В качестве короткого вывода заметим, что на рынке, во-первых, наблюдается отход от корпоративных решений в пользу общеотраслевых стандартов, причем открытые стандарты могут выигрывать конкуренцию даже в ущерб технологическому совершенству.
Во-вторых, для стриминговых технологий уже создана необходимая инфраструктура, на всех этапах прохождения и обработки сигнала.
В-третьих, базовые интернет-стандарты развиваются с приоритетным учетом задач медиастриминга. В условиях, когда видео занимает большую часть интернет-каналов, это неизбежно.
__________________________________________________