Ключевые причины для реализации низкой задержки потокового видео

Применение потоковых технологий в области развлекательных услуг постоянно растет. Например, во время проведения крупных спортивных соревнований миллиарды зрителей по всему миру смотрят их по телевизору, на ПК, смартфонах и планшетах.

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

Материал основан на техническом описании, разработанном компанией Harmonic, при участии Akamai, THEOplayer, Viaccess-Orca и NexStreaming.

Ранние форматы потоковой передачи, в основном разработанные для SVOD, были ориентированы на то, чтобы избежать двойной буферизации при обработке видео на проигрывателе. Но чтобы обеспечить гарантированное вещание на любом устройстве, в цепочке доставки и обработки видео и в первую очередь на плеере, приходилось использовать буферизацию памяти. Такой подход способствовал успешному распространению OTT, но в то же время приводил к существенной суммарной задержке в тракте доставки и обработки. Например, в протоколе HTTP Live Streaming (HLS) от Apple, выпущенном в 2009 году, рекомендовано было использовать 10-секундные сегменты, причем для начала воспроизведения проигрыватель должен буферизовать не менее трех сегментов. По этой причине для многих OTT-сервисов характерна задержка в 40 секунд и более. Позже Apple пересмотрела свою рекомендацию в пользу шестисекундных сегментов, но это все равно дает 18-секундную задержку только на стороне абонента.

Задержка в 20 секунд и более не является проблемой для сервисов SVOD, но она становится таковой для живых трансляций и спортивных событий премиум-класса. Для видео такого рода задержка ОТТ-распространения должна быть сопоставимой с задержкой в вещательной сети, а именно составлять около 5 секунд. В противном случае неизбежна негативная реакция абонента, узнающего о голе из новостной ленты или по радостным крикам из соседнего окна за 20 секунд до того, как этот гол появится у него на экране. Кроме того, обеспечение одинаковой задержки в ОТТ и вещательных сетях позволяет использовать интерактивные приложения второго экрана, так как обеспечивает временную корреляцию событий на экране телевизора и в приложении на планшете.

На рисунке 1 показана степень важности низкой задержки для различных типов видеоуслуг и контента.

Рис. 1. Шкала чувствительности к задержке вещания

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

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

ФАКТОРЫ, ОПРЕДЕЛЯЮЩИЕ ЗАДЕРЖКУ ВЕЩАНИЯ

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

Рис. 2. 

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

КАК CMAF РЕШАЕТ ВОПРОСЫ ЗАДЕРЖКИ

MPEG Common Media Application Format (MPEG-CMAF) — это стандартизированный медиаконтейнер, недавно введенный для упрощения масштабного распространения OTT-услуг.

MPEG-CMAF основан на использовании контейнера fMP4 (ISOBMFF) и может применяться как в рамках MPEG-DASH, так и c HLS-протоколом c использованием общего шифрования. Действительно, режим шифрования CBC теперь поддерживают Apple, Microsoft, Google и Adobe, что позволяет абонентским устройствам, поддерживающим разные системы DRM, принимать и открывать один и тот же зашифрованный видеофрагмент. Сохранилась необходимость составлять в отдельном манифест-файле для MPEG DASH и плейлисте для HLS, но зашифрованные медиасегменты при использовании CMAF одинаковы для обоих форматов, что значительно упрощает распространение контента и снижает нагрузку на сети.

Другим важным преимуществом MPEG-CMAF является появление возможности организации низкой задержки LLC (Low Latency Chunk — чанки с низкой задержкой). MPEG-CMAF LLC предоставляет возможность доставки сегмента небольшими частями (чанками), длительностью, например, по 200 мс, до формирования полного двухсекундного или шестисекундного сегмента. В режиме CMAF LLC передача данных ускоряется по всей цепочке, в том числе в декодере, который может начать декодирование, не дожидаясь получения всего сегмента. MPEG CMAF LLC — очень эффективный инструмент, который при использовании кодера с низкой задержкой и плеера с поддержкой DASH (так как iOS 11 поддерживает CMAF, но не LLC) может обеспечить суммарную задержку в тракте в пределах трех секунд или меньше. Конечно, проигрыватель HLS также может декодировать данный поток, но при этом будет вносить дополнительную задержку по сравнению с плеером MPEG DASH CMAF LLC (см. рисунки 3 и 4).

Чтобы в полной мере использовать преимущества CMAF LLC, необходимо обеспечить поддержку CMAF и передачи HTTP-чанков во всех звеньях цепи доставки, включая пакетизатор, вещающий сервер, CDN и плеер. Судя по тестам Harmonic и обсуждениям с партнерами, можно говорить о широкой поддержке CMAF LLC со стороны отраслевых игроков, включая операторов CDN и разработчиков плееров. Тем не менее отметим, что проигрыватели, которые поддерживают CMAF, но без LLC, по-прежнему могут декодировать видео только после приема полного медиасегмента.

Рис. 3. 

Рис. 4. 

РЕЗУЛЬТАТЫ ПРАКТИЧЕСКОГО ПРИМЕНЕНИЯ

Совместными усилиями компаний Harmonic и Akamai была реализована демонстрация работы комплексной системы CMAF LLC, для OTT-доставки видео в реальном времени с задержкой до пяти секунд. Но, как известно, условия реальной среды могут отличаться от демонстрационных. Поэтому, поскольку технология CMAF LLC уже интегрирована в продукты Harmonic, производитель совместно с партнерами и клиентами начал проводить ее испытания в экосистемах, включающих разные компоненты, от локальных устройств до облачных SaaS-решений. Передача видео велась с использованием общественных или частных CDN-сетей на телеприставки путем потоковой передачи через управляемые сети, а также на смартфоны по сетям LTE.

УСЛОВИЯ ИСПЫТАНИЙ

В следующих разделах представлена сводка первых результатов, собранных в реальных условиях. Предлагается подробный обзор того, чего можно добиться с помощью имеющихся решений CMAF LLC. Тестовая система включала два экрана: один воспроизводил видео, переданное по эталонному вещательному каналу, а другой экран (телевизора или смартфона) демонстрировал видео, доставленное с применением технологии OTT DASH CMAF LLC. Задача состояла в том, чтобы обеспечить одинаковую задержку в вещательной сети и на OTT-платформе.

ЭТАЛОННАЯ ВЕЩАТЕЛЬНАЯ СЕТЬ

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

Для вещания необходимо высокое качество видеоизображения и низкая скорость, что требует предварительной фильтрации, предварительного анализа изображения, использования алгоритмов многопроходного кодирования и длинных групп кадров (GOP). Каждый из этих инструментов компрессии добавляет задержку, поэтому вклад кодера в суммарную задержку в вещательной сети составляет более 90%. Помимо вещательного кодера, задержка добавляется главным образом мультиплексорами/скремблерами, модуляторами, спутниковым трактом (~ 250 мс) и декодером в абонентском устройстве. Можно уменьшить задержку самого кодера за счет реализации кодера с более низкой или даже сверхнизкой задержкой, но это будет влиять на качество видео или битрейт кодера. В большинстве случаев снижение задержки не является основной задачей вещателей. Пока она составляет около пяти секунд, основное внимание вещателей и операторов уделяется высокому качеству видео при минимальной скорости передачи данных. Это ключевые факторы, позволяющие соответствовать экономическим и конкурентным требованиям их бизнес-моделей.

ВНЕДРЕНИЕ DASH CMAF LLC НА ГОЛОВНОЙ СТАНЦИИ

Задержка в цепочке DASH CMAF LLC может сильно различаться в зависимости от метода реализации (на аппаратной или облачной платформе) и стабильности пропускной способности сети. Если OTT-платформа развернута на аппаратной платформе, то ABR-кодер обычно получает тот же сигнал, что и вещательный кодер. Поскольку качество видео и скорость битрейта являются общими задачами для операторов вещания и OTT-услуг, то кодеры в обоих случаях дают схожую задержку. Остальная часть цепочки DASH CMAF LLC (пакетизатор, сервер вещания, CDN и плеер) вносит незначительный вклад в общую задержку, особенно при использовании сетей доступа с хорошей пропускной способностью (например, проводные сети). В этом случае при использовании двухсекундных сегментов и фрагментов CMAF длительностью 100 мс средняя совокупная задержка видео от вещания до его отображения на абонентском устройстве составляла около 5,5 секунд, то есть примерно столько же, сколько и в вещательной сети (см. рисунок 5).

Рис. 5. Рабочий процесс DASH CMAF LLC, реализованный на аппаратной платформе 

ВНЕДРЕНИЕ DASH CMAF LLC ПРИ ОБЛАЧНОЙ РЕАЛИЗАЦИИ OTT

Поскольку все больше операторов рассматривают применение облачной инфраструктуры для развертывания OTT-сервисов, в Harmonic провели тестирование с использованием видео SaaS от Harmonic. Производительность кодера Harmonic, включая задержку, была одинаковой, независимо от того, работал он в составе локального или облачного решения (см. рисунок 6).

Рис. 6. Внедрение DASH CMAF LLC при облачной реализации

Основная трудность облачной реализации заключается в том, что сигнал из аппаратной должен быть доставлен до облачного сервиса транскодирования. Обычно для преобразования студийного сигнала в IP-поток, который может быть отправлен в облако, требуется кодер для межстудийного обмена. Такие кодеры обеспечивают видеопоток хорошего качества с задержкой в несколько сотен миллисекунд. Затем поток IP отправляется в облако через управляемую сеть с хорошим QoS или через открытый Интернет. 

В зависимости от качества (QoS) используемой сети, может появиться необходимость защиты потока от ошибок с помощью помехоустойчивого кодирования (FEC) или за счет повторных передач. Эти методы защиты реализуются довольно легко, однако приводят к увеличению задержки. Ниже приведена таблица, в которой обобщенно показано, как уровень помехозащищенности влияет на задержку на этапе доставки потока в облако.

Таблица 1. Влияние режима помехозащищенности на задержку

В ходе тестов компания Harmonic обнаружила, что все процессы, связанные с загрузкой потока в облако, в большинстве регионов добавляли дополнительные 1,4 секунды задержки. В результате общая задержка HD-потока с момента его выхода из аппаратной до начала воспроизведения плеером при использовании облачных систем компрессии и доставки составляла приблизительно семь секунд.

ВЛИЯНИЕ КАЧЕСТВА СЕТИ ДОСТУПА НА ЗАДЕРЖКУ В ПЛЕЕРЕ

Приведенные результаты были получены в условиях распространения видео по качественным сетям доступа, как правило, по управляемым сетям, с хорошим Wi-Fi-покрытием. В таких случаях сетевой буфер DASH CMAF LLC плеера может быть уменьшен до минимума без риска его опустошения из-за перегрузки сети.

В сетях LTE, характеризующихся более длительными задержками и быстрым изменением пропускной способности, OTT-потоки сталкиваются с более сложными условиями доставки мультимедиа.

Тесты, проводившиеся в сетях LTE, подтвердили важность увеличения глубины сетевого буфера на 1-2 секунду для обеспечения непрерывности обработки и воспроизведения видео (см. таблицу 2).

Таблица 2. Результаты испытаний

Таким образом, качество сети доступа является основным фактором, определяющим задержку, а следовательно, и качество восприятия услуги (QoE). С этой точки зрения возможность адаптироваться к изменяющимся условиям сети нужнее, чем доработка клиентской части.

ВЛИЯНИЕ UHD-РАЗРЕШЕНИЯ НА ЗАДЕРЖКУ В OTT-СЕТИ

Необходимость распространять спортивные события премиум-класса с задержкой не больше, чем в вещательных сетях, — один из основных факторов внедрения решений с низкой задержкой вещания. Эти премиум-события также должны доставляться на экраны телевизоров в UHD-формате. Самым простым способом охватить большую аудиторию UHD-вещанием часто оказывается OTT-доставка по оптоволоконному соединению. Поэтому стриминг UHD с низкой задержкой также становится важной задачей В большинстве испытаний систем с низкой задержкой, проведенных компанией Harmonic, включая тесты с облачным транскодированием, использовалось как раз видео формата UHD. Мы не обнаружили каких-либо существенных различий в задержке между HD и UHD, поэтому приведенные выше цифры применимы и к UHD.

АЛЬТЕРНАТИВЫ DASH CMAF LLC

Как показано выше, DASH CMAF LLC — это проверенная на практике технология, снижающая суммарную задержку. Компания Harmonic и некоторые ее партнеры являются активными сторонниками этой технологии, однако существуют и другие варианты решения проблемы. Рассмотрим эти альтернативы.

ОПТИМИЗАЦИЯ ПОТОКОВОЙ ПЕРЕДАЧИ ABR С ПРИМЕНЕНИЕМ МЕХАНИЗМОВ HLS И DASH

Сегодня подавляющее большинство OTT-проектов реализовано на базе адаптивной потоковой HTTP-передачи с использованием HLS или DASH. Поскольку плеерам необходимо буферизовать определенное количество сегментов, прежде чем они смогут начать декодировать видео (три в случае HLS), существует прямая зависимость между размером сегмента и суммарной задержкой. Одним из наиболее простых подходов к снижению суммарной задержки является простое сокращение длительности сегмента. Основное преимущество такого подхода в том, что он не требует никакого изменения компонентов экосистемы. Тем не менее эта опция имеет некоторые важные ограничения:

• Согласованность экосистемы. Cокращение длительности сегмента в технологии DASH и особенно в HLS возможно с определенными оговорками. Для пакетов формата HLS компания Apple изначально установила минимальную длительность сегмента в 10 секунд, которая затем была сокращена до шести секунд. И хотя опуститься ниже этого порога технически возможно, это потребует нестандартной реализации плеера. Кроме того, это означает, что вся экосистема (пакетизатор, сервер-источник, CDN, клиент, проигрыватель) должны согласовать возможность совместной работы в таком режиме.

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

• Качество видео. Как показано на рисунке 7, уменьшение длительности сегмента с 10 до 2 секунд не влияет на качество видео. Тем не менее снижение ниже двухсекундного порога приведет к использованию кодером более короткой последовательности кадров, что, в свою очередь, немедленно повлечет за собой снижение качества видео. А снижения длительности сегмента двухсекундного порога, к сожалению, недостаточно для обеспечения задержки, сопоставимой с вещательной.

Рис. 7. Влияние сокращения длительности сегмента

Таким образом, задержку в стандартных системах ABR-стриминга на базе HLS и DASH снизить можно, но до определенного уровня. Переход в режим с действительно низкой задержкой приводит к риску появления несогласованностей в экосистеме, дополнительным затратам на настройку и снижению качества восприятия услуги (QoE).

WEBRTC

WebRTC — это протокол с открытым исходным кодом, изначально разработанный для взаимодействия между браузерами в одноранговых сетях. С точки зрения показателей задержки протоколы WebRTC и Web-socket актуальны в первую очередь для приложений со сверхнизкой задержкой. Типичные приложения, для которых предназначен WebRTC, — задачи близкие к вещанию в реальном времени (например, приложения для интерактивных социальных сетей, видеоконференции и т. д.). Следует признать, что с точки зрения задержки данная технология может работать даже лучше, чем это необходимо для соответствия параметрам задержки в вещательных сетях. Однако к ОТТ-платформам предъявляются и другие требования.

Конкурентоспособная система OTT-услуг должна удовлетворять значительно большему количеству требований, чем просто доставка живого контента с минимальной задержкой. Современные OTT-платформы должны обеспечивать защиту контента, масштабируемость услуг, поддерживать нелинейные сервисы и т. д. Технология WebRTC как таковая таких возможностей не дает. В момент начала сеанса WebRTC требует выделенных серверов, имеющихся не во всех CDN, поэтому масштабируемость технологии вызывает сомнения. Более того, для WebRTC требуется другая версия клиента, поэтому понадобится реинжиниринг всей базы HLS и DASH клиентов.

КОМПЛЕКСНОЕ СРАВНЕНИЕ РАЗЛИЧНЫХ РЕШЕНИЙ

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

Таблица 3, сравнение потоковых технологий с низкой задержкой

* Режим CMAF Low Latency Chunk с поддержкой передачи кодированных фрагментов по HTTP-протоколу.

** Низкая по сравнению с ABR, в связи с тем, что для доставки контента в HLS и DASH используются одни и те же сегменты мультимедиа и общая схема шифрования DRM (например, CBCS).

На рисунке 8 показано размещение этих технологий на комплексной шкале «конкурентоспособности».

Рисунок 8. Позиционирование технологии потоковой передачи с низкой задержкой

КАКИМ БУДЕТ СЛЕДУЮЩИЙ ШАГ В ОТНОШЕНИИ CMAF?

Результаты тестов технологии CMAF показали ее работоспособность в рамках всей экосистемы и возможность ее коммерческой реализации. Следующие шаги предполагают оптимизацию. В 2017 году CMAF был стандартизирован, а в 2018 году обеспечена его совместимость с клиентскими приложениями и проведены первые комплексные испытания. В этом, 2019 году начнется коммерческое внедрение технологии при поддержке режима LLC (Low latency Chunk) в HLS со стороны Apple.

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

ЗАКЛЮЧЕНИЕ

Хотя эта статья посвящена режиму низкой задержки, применение CMAF сфере ОТТ набирает обороты безотносительно этой опции. Это связано с тем, что применение CMAF унифицирует уровни доставки и защиты контента. Это позволяет вещательным платформам, которые должны поддерживать и DASH, и HLS, минимизировать затраты на доставку и хранение трафика, что является ключевым для их бизнеса. Несмотря на существование альтернатив, CMAF LLC является единственным практическим вариантом решения проблемы задержки, сохраняющим при этом другие ключевые возможности, необходимые для запуска конкурентоспособной услуги OTT — масштабируемой, с единой системой шифрования, запущенной на существующей инфраструктуре CDN и с использованием имеющейся базы клиентов. Масштабируемость, реализация тергетированной рекламы и геоблокировок, защита контента с применением DRM и видео премиального уровня стали уже обязательным функционалом, отсутствие которого не компенсируется низкой задержкой. Вот почему в своих OTT-решениях Harmonic внедрил и CMAF LLC, и передачи кодированных фрагментов по HTTP-протоколу.

Компания Harmonic совместно с технологическими партнерами Akamai, THEOplayer, Viaccess-Orca и NexStreaming, работающими в области CDN и разработки плееров, уверена в возможности коммерческого развертывания CMAF и рекомендует вещателям и операторам начать внедрение DASH CMAF LLC уже сегодня. 

Источник