Будь то матч чемпионата мира по футболу, Суперкубок или финал Открытого чемпионата Франции, посмотреть его с друзьями в субботу вечером — это #цель. К сожалению, не все из нас могут достать билеты и отправиться в путешествие через города, страны или континенты, чтобы посетить эти мероприятия. К счастью, прямые трансляции позволяют наблюдать за всем происходящим практически в режиме реального времени.
Но вопрос только в том, насколько близко к реальному времени мы говорим?
Потоковое видео в значительной степени обеспечивается благодаря видеопротоколу под названием HLS (HTTP Live Streaming). В то время как происхождение и основы HLS объясняются в другом материале нашего блога, текущий материал будет посвящен тому, как HLS устранил один из своих самых больших недостатков: задержку.
Для начала давайте вкратце рассмотрим, как работает HLS.
Путь HLS
Сначала мы попытаемся понять, как работает HLS и делает возможным потоковое вещание в реальном времени. Вот как выглядит типичный поток потоковой системы HLS:
- Аудио/видео поток, захваченный устройствами ввода, кодируется и поступает на медиасервер.
- Медиасервер транскодирует поток в HLS-совместимый формат с несколькими вариантами ABR, а также создает файл списка воспроизведения для использования видеоплеерами.
- Затем медиасервер передает медиапоток и файл списка воспроизведения клиентам либо напрямую, либо через CDN, выступая в качестве сервера происхождения.
- Проигрыватели на стороне клиента используют файл списка воспроизведения для навигации по видеосегментам. Эти сегменты обычно являются «кусочками» создаваемого видео с определенной продолжительностью (называемой размером сегмента, обычно от 2 до 6 секунд).
- Список воспроизведения обновляется в зависимости от размера сегмента, и игроки могут выбирать указанные в нем сегменты, исходя из порядка воспроизведения и требуемого качества видео.
Несмотря на то, что HLS предлагает надежный способ потоковой передачи видео, его высокий уровень задержки может создавать препятствия и проблемы для многих стримеров или дистрибьюторов видео. Согласно первоначальной спецификации, плеер должен заранее загрузить медиафайлы перед воспроизведением. Это делает HLS по своей сути протоколом с более высокой задержкой, составляющей около 30-60 секунд.
Настройка HLS на низкую задержку
Все были заинтересованы в реализации HLS, но высокая латентность была серьезным препятствием. Поэтому разработчики и энтузиасты начали искать обходные пути для снижения задержки и доработки протокола для эффективного использования. Некоторые из этих методов дали настолько положительные результаты, что они начали становиться негласным стандартом наряду со спецификацией HLS. Ниже перечислены два из этих методов:
Уменьшение размера сегмента по умолчанию
Когда Apple представила HLS, типичный размер сегмента составлял 10 секунд. Большинство разработчиков HLS сочли его слишком длинным, поэтому Apple решила уменьшить его до 6 секунд. Общая задержка может быть уменьшена за счет уменьшения размера сегмента и размера буфера плеера.
Однако это сопряжено с некоторыми проблемами. Некоторые из них включают увеличение общего битрейта, буферизацию или джиттер для устройств с плохими сетевыми условиями. Идеальный размер сегмента должен определяться в зависимости от целевой аудитории и может составлять от 2 до 4 секунд.
Загрузка медиафайлов с помощью более быстрых протоколов
Основной причиной использования HLS для потокового вещания в прямом эфире является масштабируемость, надежность и совместимость с плеерами, которую он обеспечивает на всех платформах, особенно по сравнению с другими протоколами. Это сделало HLS незаменимым для доставки видео на сегодняшний день.
Но вклад первой мили (также известный как ingest) от стека HLS может быть заменен протоколами с меньшей задержкой для снижения общей задержки.
Ввод HLS обычно заменяется вводом RTMP, который пользуется широкой поддержкой кодеров/сервисов и зарекомендовал себя как экономически эффективное решение. Поток, полученный с помощью RTMP, затем транскодируется для поддержки HLS с помощью медиасервера перед передачей контента. Несмотря на эксперименты с другими протоколами, такими как WebRTC и SRT, RTMP остается самым популярным вариантом.
Эволюция HLS к LL-HLS
Задержка в HLS стала представлять собой серьезное препятствие, приводящее к не самым лучшим впечатлениям пользователей. Это происходило все чаще, поскольку HLS широко внедрялся по всему миру. Настроить HLS было недостаточно, и все искали лучшие и более надежные решения.
Именно в 2016 году команда инженеров Twitter Periscope внесла ряд серьезных изменений в свою реализацию, чтобы добиться низкой задержки при использовании HLS. Эта собственная версия HLS, часто называемая LHLS, обеспечивала задержку от 2 до 5 секунд.
DASH, главный конкурент HLS, в 2017 году предложил решение с низкой задержкой на основе chunked CMAF, после чего в 2018 году было разработано решение HLS с низкой задержкой на основе сообщества (L-HLS). Этот вариант был в значительной степени вдохновлен LHLS от Periscope и использовал кодирование передачи в виде кусков (CTE) для снижения задержки. Этот вариант часто называют Community Low Latency HLS (CL-HLS).
Пока эта версия HLS набирала популярность, компания Apple решила выпустить собственное расширение протокола под названием Low Latency HLS (LL-HLS) в 2019 году. Его часто называют Apple Low Latency HLS (ALHLS). Эта версия HLS предлагала низкую задержку, сравнимую с CL-HLS, и обещала совместимость с устройствами Apple. С тех пор LL-HLS был объединен со спецификацией HLS и технически стал единым протоколом.
Как LL-HLS снижает задержку
В этом разделе мы рассмотрим изменения, которые LL-HLS привносит в HLS, делая возможным потоковое вещание с низкой задержкой. В спецификацию этого протокола были внесены два основных изменения, ответственные за его низкую латентность. Первое — это разделение сегментов на части и доставка их, как только они становятся доступными. Второе — информирование игрока о данных, которые будут загружены следующими, еще до того, как эти данные будут доступны.
Разделение сегментов на части
Видеосегменты далее делятся на части (аналогично чанкам, используемым в CMAF). Эти части — просто «меньшие сегменты» с определенной продолжительностью — представлены тегом EXT-X-PART в медиа плейлисте.
Плееры могут заполнять свой буфер более эффективно, публикуя части во время создания сегмента. Уменьшение размера буфера на стороне плеера при таком подходе приводит к снижению задержки. После завершения работы эти части коллективно заменяются соответствующими сегментами, которые остаются доступными в течение более длительного периода времени.
Подсказки перед загрузкой
Когда LL-HLS был впервые представлен, он имел HTTP/2 push, указанный в качестве требования на стороне сервера для отправки новых данных клиентам. Многие коммерческие CDN-провайдеры в то время не поддерживали эту функцию, что привело к большой путанице.
Apple решила эту проблему в одном из последующих обновлений, заменив HTTP/2 push подсказками предварительной загрузки. Они решили включить поддержку подсказок предварительной загрузки, добавив новый тег EXT-X-PRELOAD-HINT в список воспроизведения, что позволило снизить накладные расходы.
С помощью подсказки предварительной загрузки видеоплеер может предвидеть, какие данные будут загружены следующими, и может отправить запрос на URI из подсказки, чтобы получить более быстрый доступ к следующей части/данным. Серверы должны блокировать все запросы на данные подсказки предварительной загрузки и возвращать их, как только данные становятся доступными, тем самым уменьшая задержку.
Взгляд на медиаплейлист LL-HLS
Теперь давайте на примере рассмотрим, как эти теги указываются в файле медиаплейлиста. Мы будем считать, что размер сегмента составляет 6 секунд, а размер части — 200 миллисекунд. Мы также предположим, что 2 сегмента (сегменты A и B) были полностью проиграны, а 3-й сегмент (сегмент C) все еще генерируется. Этот сегмент публикуется в виде списка частей в порядке воспроизведения, поскольку он еще не завершен.
Ниже приведен пример списка воспроизведения медиафайла (файл M3U8).
Проигрыватели, которые еще не поддерживают LL-HLS, обычно игнорируют такие теги, как EXT-X-PART и EXT-X-PRELOAD-HINT, что позволяет им обрабатывать список воспроизведения традиционным HLS и загружать сегменты с более высокой задержкой.
HLS с низкой задержкой на устройствах других производителей Apple
Новый и улучшенный HLS имеет задержку около 3 секунд или меньше. Единственным разумным конкурентом для этого протокола является LL-DASH. Но Apple поддерживает DASH не на всех своих устройствах. Таким образом, LL-HLS является единственным протоколом с низкой задержкой прямого эфира, который имеет широкую поддержку на стороне клиента, включая устройства Apple.
Одним из главных преимуществ использования LL-HLS является его обратная совместимость с устаревшими HLS-плеерами. Проигрыватели, не поддерживающие этот вариант, могут вернуться к стандартному HLS и по-прежнему работать с более высокой задержкой. Поскольку этот протокол требовал от плееров начинать загрузку незавершенных медиасегментов вместо того, чтобы ждать, пока они станут полностью доступными, изменения в спецификации затрудняли быструю адаптацию этого протокола для всех плееров.
Потребовалось некоторое время, чтобы большинство устройств, не принадлежащих компании Apple, начали поддерживать LL-HLS. Сейчас он широко поддерживается почти на всех платформах с относительно новыми версиями плееров. Несмотря на то, что некоторые из них планировали поддержку протокола с момента его появления, большинство из них являются новыми и улучшают свою совместимость в настоящее время.
Вот несколько популярных плееров с разных платформ, которые поддерживают LL-HLS в полном объеме:
- AVPlayer (iOS)
- Exoplayer (Android)
- THEOPlayer
- JWPlayer
- HLS.js
- VideoJS
- AgnoPlay
Сравнение LL-HLS, LL-DASH и WebRTC
Здесь мы сравниваем три протокола LL-HLS, LL-DASH и WebRTC по шести параметрам: совместимость, способ доставки, поддержка ABR, безопасность, задержка, лучший вариант использования.
Совместимость
- LL-HLS обеспечивает хорошую поддержку всех устройств и браузеров Apple. Он получает все большую поддержку для большинства устройств, не относящихся к Apple.
- LL-DASH поддерживает большинство устройств и браузеров, не относящихся к Apple, но не поддерживается ни на одном устройстве Apple.
- WebRTC поддерживается всеми популярными браузерами и платформами.
Способ доставки
Сначала рассмотрим несколько терминов, используемых в CMAF.
Chunked Encoding (CE) — это техника, используемая для создания пригодных для публикации «кусков». При сложении вместе эти фрагменты образуют видеосегмент. Куски имеют заданную продолжительность и являются наименьшей единицей, которую можно опубликовать.
Chunked Transfer Encoding (CTE) — это метод, используемый для доставки «кусков» по мере их создания в последовательном порядке. При использовании CTE достаточно одного запроса на сегмент, чтобы получить все его фрагменты. Передача заканчивается, как только отправлен фрагмент нулевой длины. Этот метод позволяет использовать для передачи даже небольшие фрагменты.
-LL-HLS использует Chunked Encoding для создания «частей» или «кусков» сегмента. Но вместо использования Chunked Transfer Encoding, этот протокол использует свой собственный метод доставки фрагментов по TCP. Клиент должен сделать запрос на каждую отдельную часть, вместо того, чтобы просто запросить весь сегмент и получить его по частям.
- LL-DASH использует Chunked Encoding для создания фрагментов и Chunked Transfer Encoding для их передачи по TCP.
- WebRTC использует протокол передачи в реальном времени (RTP) для передачи видео- и аудиопотоков по UDP.
Поддержка адаптивного битрейта (ABR)
Адаптивный битрейт (ABR) — это метод динамической регулировки уровня сжатия и качества видеопотока в соответствии с доступностью полосы пропускания. Это существенно влияет на качество потокового видео для зрителя.
- LL-HLS поддерживает ABR.
- LL-DASH поддерживает ABR.
- WebRTC не поддерживает ABR. Однако для динамической регулировки качества видео используется похожая техника под названием Simulcast.
Безопасность
Как LL-HLS, так и LL-DASH поддерживают шифрование мультимедиа и пользуются такими функциями безопасности, как аутентификация с помощью маркера и управление цифровыми правами (DRM).
WebRTC поддерживает сквозное шифрование медиа для передачи, аутентификации пользователя, файла и маршрута. Этого часто достаточно для целей DRM.
Задержка
Как LL-HLS, так и LL-DASH имеют задержку от 2 до 5 секунд.
WebRTC, с другой стороны, имеет субсекундную задержку ~500 миллисекунд.
Лучший вариант использования
И LL-HLS, и LL-DASH лучше всего подходят для потоковой передачи событий, которые должны быть доставлены миллионам зрителей. Они часто используются для прямых трансляций спортивных событий.
WebRTC очень часто используется для таких решений, как видеоконференции, которые требуют минимальной задержки и не предполагают большого масштабирования.
Теперь, когда HLS поддерживает потоковое вещание с низкой задержкой, он полностью готов завоевать пространство потокового видео, готовый без проблем обслуживать миллионы болельщиков, наблюдающих за тем, как их любимая команда играет решающий матч. Если вы хотите начать прямую трансляцию самостоятельно или создать приложение, которое будет поддерживать прямые трансляции, LL-HLS останется вашим лучшим другом.