Хотя задержка (лаг) привлекает больше всего внимания в качестве ключевого показателя эффективности (KPI) при стриминге живых мероприятий, синхронизация между зрителями часто оказывается еще важнее. Выделяются две основные причины.
Первая — предотвращение спойлеров: болельщики, смотрящие трансляцию на телевизоре, телефоне или в социальной сети, рассчитывают увидеть один и тот же момент примерно в одно и то же время. Если одна платформа опережает остальные, зритель может увидеть комментарий о победном голе в соцсетях до того, как этот момент дойдет до его собственного стрима.
Вторая — социальное взаимодействие в реальном времени, когда стабильная задержка позволяет болельщикам вместе праздновать, спорить и реагировать синхронно, а не говорить невпопад на разных временных шкалах.
По этим и другим причинам при выборе платформы для लाइव-стриминга продюсеры должны уделять внимание как задержке, так и синхронизации. Как вы узнаете из этой статьи, Dolby OptiView обеспечивает точное программное управление обоими параметрами, позволяя продюсерам настраивать параметры производства в соответствии со своими конкретными бизнес-целями.
Задержка против синхронизации: две разные цели
Давайте определимся с терминами. Задержка — это разница между тем, что реально происходит на поле или площадке, и тем, что зритель видит в тот же момент. Задержку часто называют «от стекла до стекла» (glass-to-glass), имея в виду время от захвата действия объективом камеры до его отображения на устройстве воспроизведения зрителя.
Синхронизация означает, видят ли все ваши зрители на разных устройствах, в разных местах и сетях одну и ту же точку потока в один и тот же момент времени. Несколько терминов дополнительно определяют синхронизацию. Дрифт (drift) описывает, насколько далеко конкретный зритель отклонился от целевой задержки. Размах зрителей (viewer spread) — это максимальный дрифт между любыми двумя зрителями, и он часто считается наиболее важным метрическим показателем для обеспечения справедливости и общего опыта.
То, как OptiView управляет задержкой и синхронизацией, зависит от протокола, поэтому начнем с них. OptiView поддерживает три протокола доставки, каждый из которых имеет свой профиль задержки: WebRTC для доставки менее чем за секунду (0,2–1 с), HESP для HTTP-стриминга с низкой задержкой (1–9 с, причем менее секунды достигается в строго контролируемых средах) и HLS для стандартной доставки (от 9 с и выше).
Давайте рассмотрим каждый из них подробнее.
WebRTC против HESP и HLS: задержка, синхронизация и масштаб
WebRTC
WebRTC — это вариант с ультранизкой задержкой, которая может составлять от 0,2 секунды «от стекла до стекла». Это протокол, используемый в большинстве приложений для конференц-связи.
При задержке менее секунды зрители естественным образом тесно синхронизированы. Тем не менее стек WebRTC в OptiView использует встроенные механизмы WebRTC, включая джиттер-буферы и контроль синхронизации, для сглаживания сетевого джиттера и предотвращения дрифта, однако здесь нет отдельного окна джиттера в стиле HTTP, как в HESP и HLS.
WebRTC лучше всего подходит для сценариев с высокой степенью интерактивности, таких как гемблинг, живые аукционы, совместный просмотр (co-watch), телеприсутствие или управление в реальном времени. Он может масштабироваться через CDN реального времени, но этот стек более специализирован, чем стандартный HTTP-стриминг, и стоимость на одного зрителя обычно выше, чем у HESP или HLS.
Протокол высокоэффективного стриминга (HESP)
HESP — это вариант HTTP с низкой задержкой для интерактивных потоков «один ко многим» с задержкой от 1 до 9 секунд. Это делает HESP идеальным решением для спортивных ставок, интерактивных спортивных трансляций, онлайн-занятий и аналогичных сценариев, требующих низкой задержки, интерактивности, синхронизации и масштабируемости.
HESP работает через стандартные HTTP CDN с адаптивным битрейтом и быстрой сменой каналов, но требует проигрывателей с поддержкой HESP и дополнительных возможностей CDN. С точки зрения затрат HESP занимает промежуточное положение между WebRTC и HLS. Как описано ниже, OptiView управляет синхронизацией с помощью средств контроля дрифта вокруг целевой задержки.
HTTP Live Streaming (HLS)
HLS может обеспечивать задержку от 9 секунд и более, что делает его оптимальным выбором для ОТТ-трансляций в стиле расслабленного просмотра (lean-back). В таких приложениях отставание на несколько секунд от прямого эфира допустимо, а интерактивность ограничена или не критична ко времени.
Главные сильные стороны HLS — масштабируемость, совместимость и качество видео. HLS вписывается в существующие рабочие процессы HLS, работает в экосистемах Apple, на смарт-телевизорах и старых плеерах, а также использует стандартные CDN со знакомыми схемами работы. В OptiView для HLS используются те же средства управления задержкой, что и для HESP.
Поддерживая три протокола со значительно различающимися профилями задержки, синхронизации, масштаба и стоимости, Dolby OptiView Streaming позволяет продюсеру сопоставить транспорт с конкретным форматом взаимодействия, а не подгонять любые сценарии под один конвейер. Оператор ставок может запустить WebRTC, вещатель — HLS, а интерактивная спортивная трансляция может разместиться посредине на базе HESP.
Потребности и приоритеты каждого издателя уникальны. Если вы не уверены, какой протокол лучше всего подходит для вашего спортивного лайв-сценария, вам не обязательно решать эту задачу в одиночку. Команда OptiView поможет вам выбрать правильное сочетание WebRTC, HESP и HLS для зрителей на самых разных устройствах и с разными типами подключения. Во многих случаях использование нескольких протоколов одновременно обеспечивает наилучший общий результат для вашей аудитории.
Как OptiView управляет задержкой потока
Чтобы понять, как OptiView управляет задержкой и синхронизацией, вам сначала потребуется общее представление о рабочем процессе OptiView. Если кратко, вы создаете канал в OptiView из трех основных компонентов: приема (ingest), движка (engine) и одной или нескольких дистрибуций (distributions). Компонент приема принимает ваш вкладной фид (contribution feed). Движок перекодирует и упаковывает этот фид в HTTP-выходы, создавая рендеринги HESP и HLS для доставки.
Затем дистрибуции передают эти выходы через CDN и при необходимости могут быть настроены с использованием источника WebRTC для доставки в реальном времени (менее секунды) наряду с HESP и HLS. Плеер OptiView подключается к дистрибуции и воспроизводит лучший из доступных протоколов для каждого зрителя.
Как показано на Рисунке 1, на этом этапе конвейера задержку добавляют два звена: ваш вкладной кодировщик (contribution encoder) и транскодер в движке OptiView. Это типично для всех облачных систем доставки живого видео: вкладной кодировщик захватывает событие у источника и отправляет высококачественный файл mezzanine в облако. Оттуда облачный сервис транскодирует входящий поток для создания требуемых форматов и профилей и доставляет их в CDN.
В OptiView этот рабочий процесс от вклада до транскодера происходит только с выходами HLS и HESP. Поток WebRTC поступает клиентам напрямую через систему с минимальной обработкой.
Что добавляет задержку в живом потоке
Все вкладные кодировщики имеют собственные пресеты, которые управляют качеством и задержкой. Как вы, наверное, знаете, кодирование с очень низкой задержкой может ухудшить качество видео. Такие методы, как упреждающий просмотр (lookahead), которые помогают кодировщикам принимать более разумные решения о сжатии, неизбежно увеличивают задержку. Поскольку вкладные кодировщики обычно создают файлы mezzanine с высоким битрейтом, работа с низкой задержкой на этом этапе обычно оказывает минимальное влияние на качество. На Рисунке 1 мы предполагаем, что вкладной кодировщик добавляет 0,5 секунды задержки.
Внутри OptiView механизм перекодирует каналы योगदान (contribution feeds) для доставки по протоколам HESP или HLS. Когда в качестве выходного протокола выбран HESP, механизм минимизирует задержку, ограничивая используемый набор инструментов кодирования и обеспечивая качество, сравнимое с другими низкозадержными кодировщиками на рынке.
Когда выбран только протокол HLS, транскодер использует более продвинутые методы кодирования, такие как более длинные структуры GOP и упреждающий просмотр (look-ahead), что обеспечивает заметно более высокое качество изображения при том же битрейте. На рисунке 1 мы предполагаем, что механизм OptiView также добавляет 0,5 секунды задержки. Обратите внимание, что фактические задержки будут различаться в зависимости от развернутых протоколов и других деталей настройки.
Два элемента управления: целевая задержка и окно синхронизации
К этому моменту видео уже находится в системе, и OptiView может управлять задержкой и синхронизацией. OptiView делает это с помощью двух элементов управления: один задает целевую задержку, а набор элементов управления смещением (drift) удерживает зрителей близко к этой цели.
В частности, вы задаете желаемую задержку с помощью параметра targetOffset, который можно установить в двух местах. Во-первых, вы можете настроить значение targetOffset по умолчанию в панели управления или API, что задает цель синхронизации для всех плееров. Вы можете переопределить это на стороне плеера, используя тот же элемент управления targetOffset в конфигурации задержки плеера, что позволяет настраивать задержку для каждого источника или каждого зрителя по отдельности.
Как показано на рисунке 1, параметр targetOffset начинает действовать после того, как видео было принято (ingested) в OptiView, поэтому он не учитывает задержку кодировщика контрибьюции. Однако он вычитает любую задержку, вносимую транскодером. Таким образом, если перекодирование OptiView добавляет 0,5 секунды задержки, а вы настраиваете цель в 10 секунд, OptiView сообщает плееру воспроизводить поток примерно на 9,5 секунды позади актуального края (live edge) OptiView. Это позволяет издателям устанавливать желаемую задержку, не задумываясь о том, какую задержку добавляет транскодер.
Управление синхронизацией зрителей с помощью окон смещения (drift windows)
После установки параметра TargetOffset второй задачей является удержание зрителей на целевом значении. Для поддержания синхронизации OptiView позволяет определить допустимое окно смещения вокруг targetOffset с помощью двух параметров: minimumOffset и maximumOffset (рисунок 2).
Думайте о них как о границах некоторой зоны. До тех пор пока текущее смещение зрителя находится внутри этой зоны, плеер работает на нормальной скорости. Если зритель смещается за пределы зоны в любом направлении, плеер слегка изменяет скорость воспроизведения, чтобы вернуть его обратно. Значения по умолчанию составляют 0,66 от targetOffset в меньшую сторону и 1,5 от targetOffset в большую сторону, поэтому зона намеренно асимметрична, что допускает большее отставание от цели, чем опережение.
На рисунке 2 параметр targetOffset установлен на 5 секунд, что отмечено центральной линией и значком цели. Узкая зеленая полоса от 4,5 до 5 секунд показывает нормальную рабочую зону, ограниченную слева параметром minimumOffset, а справа — maximumOffset. Зрители внутри этой полосы воспроизводятся с нормальной скоростью 1,0x и не требуют никакой коррекции.
За пределами этой зеленой зоны плеер начинает корректировать смещение. Желтые зоны, расположенные в диапазонах 3–4,5 секунды и 5,5–7 секунд, соответствуют зрителям, которые отстают от цели. Здесь плеер ускоряет или замедляет воспроизведение примерно на 8%, возвращая их к отметке 5 секунд без видимого скачка.
Красная линия forceSeekOffset на отметке 7 секунд обозначает жесткий предел. Если зритель смещается за эту линию, плеер выполняет жесткий поиск (hard seek) обратно к цели. Параметр forceSeekOffset также используется для поддержания синхронизации на старых устройствах, которые не поддерживают тонкую настройку скорости воспроизведения.
Заключение
Низкая задержка и синхронизация — это связанные, но разные цели. С Dolby OptiView вы получаете гибкость в выборе целевой задержки с помощью targetOffset. Затем вы настраиваете степень удержания зрителей вокруг этой цели с помощью minimumOffset, maximumOffset и forceSeekOffset. В совокупности эти элементы управления позволяют держать зрителей синхронизированными для разделения общего момента, оставляя при этом пространство для плавного воспроизведения.
Для платформ трансляции спортивных соревнований в прямом эфире этот общий опыт имеет значение. Поддержание синхронизации зрителей помогает предотвратить спойлеры, поддерживает социальные и интерактивные функции в реальном времени и сохраняет те коллективные моменты, которые делают спортивные трансляции захватывающими.
Отличная спортивная платформа обеспечивает качество, надежность и интерактивность в нужном масштабе для укрепления лояльности подписчиков. Синхронизация — это та нить, которая связывает их воедино, создавая ощущение настоящего прямого эфира. С Dolby OptiView вы не просто управляете задержкой. Вы стабильно предоставляете общий опыт для болельщиков в любом масштабе и на ваших условиях, чтобы каждый фанат оставался в одном и том же моменте.
