Доставка живого контента YouTube через HLS

В этом документе объясняется, как использовать протокол HTTP Live Streaming (HLS) для потоковой передачи данных с видеокодера на YouTube в режиме реального времени. Этот документ предназначен для производителей видеокодеров, желающих добавить поддержку приема HLS в свои продукты. Прием HLS — хороший выбор для премиум-контента, требующего высокого качества и разрешения при относительно высокой задержке. Краткое сравнение различных протоколов приема, поддерживаемых YouTube Live Streaming, см. в статье Сравнение протоколов приема YouTube Live Streaming .

Для потоковой передачи данных в режиме реального времени с использованием HLS кодер должен отправить серию медиаплейлистов и медиасегментов на конечную точку HLS YouTube с помощью HTTP PUT или POST . С точки зрения кодера, конечная точка HLS YouTube выглядит как пассивный HTTP-сервер.

Каждый медиасегмент представляет собой собственно мультимедийный контент для короткого фрагмента потока длительностью от одной до четырёх секунд. В каждом медиаплейлисте описывается, как правильно скомпоновать медиасегменты в правильном порядке.

Требования к формату носителя

Прием HLS на YouTube предъявляет следующие требования к видео- и аудиоконтенту:

  • Видео и аудио должны быть объединены в формате M2TS.
  • Поддерживаемые видеокодеки: H.264 и HEVC.
  • Поддерживается частота кадров до 60 кадров в секунду.
  • Поддерживаются только закрытые GOP.
  • Поддерживаемый аудиокодек — AAC, поддерживается только однодорожечный звук.

Более подробные требования см. в разделе «Медиа-сегменты» .

HDR

Видео с высоким динамическим диапазоном (HDR) поддерживается с использованием кодека HEVC и имеет следующие дополнительные требования:

  • Поддерживаемые стандарты цвета: 10-битный PQ и HLG с непостоянной яркостью. В частности:
    • Формат цветности должен быть YUV 4:2:0 10-бит.
    • Функция передачи должна быть PQ (также известна как SMPTE ST 2084) или HLG (также известна как ARIB STD-B67).
    • Основные цвета должны соответствовать стандарту Rec. 2020.
    • Коэффициенты матрицы должны соответствовать стандарту Rec. 2020 с непостоянной яркостью.
  • Поддерживаются значения выборки как ограниченного диапазона (или диапазона MPEG), так и полного диапазона (или диапазона JPEG). Важно, чтобы диапазон был установлен в соответствии с диапазоном значений выборки, используемым в контенте. Рекомендуется использовать значения выборки ограниченного диапазона.

Получение URL-адреса для приема HLS

Получение URL-адреса для приема HLS из API YouTube

Чтобы получить полный URL-адрес для приема, кодировщики могут использовать API YouTube Live Streaming для вставки ресурса liveStream со следующими свойствами:

"cdn": {
  "ingestionType": "hls",
  "frameRate": "variable",
  "resolution": "variable"
}

В ответе API поле cdn.ingestionInfo.ingestionAddress указывает основной URL-адрес для приёма данных, а поле cdn.ingestionInfo.backupIngestionAddress — резервный URL-адрес для приёма данных. Подробнее см. в документации по ресурсу liveStreams .

Получение URL-адреса для приема HLS из YouTube Creator Studio

В веб-интерфейсе YouTube Creator Studio после нажатия кнопки «Создать трансляцию» YouTube отображает «Ключ трансляции», состоящий из букв, цифр и дефисов. Этот секретный ключ идентифицирует как автора, так и трансляцию на YouTube.

Из этого ключа потока можно создать URL-адрес HLS следующим образом:

https://a.upload.youtube.com/http_upload_hls?cid=$STREAM_KEY&copy=0&file=

... где $STREAM_KEY — ключ потока, отображаемый в веб-интерфейсе. Например: https://a.upload.youtube.com/http_upload_hls?cid=abcd-efgh-ijkl-mnop-qrst&copy=0&file=

Для дополнительной надежности вы можете передать резервную вторую копию приема на этот резервный URL:

https://b.upload.youtube.com/http_upload_hls?cid=$STREAM_KEY&copy=1&file=

Обратите внимание, что резервная копия имеет два отличия от основного URL: изменились и имя хоста, и параметр copy= . При получении резервной копии необходимо передать значение параметра copy= отличное от значения при получении основной копии, чтобы избежать повреждения потока.

Заполнение URL-адреса для приема HLS

URL-адреса, полученные любым из этих методов, представляют собой неполные шаблоны; каждый из них заканчивается пустым параметром запроса file= =. Для формирования окончательного URL-адреса кодер должен добавить имя файла медиа-плейлиста или медиа-сегмента в конец URL-адреса, тем самым завершив параметр file= .

К значению параметра file= применяются следующие правила:

  • Кодер может создать имя файла списка воспроизведения мультимедиа или сегмента мультимедиа из букв, цифр, подчеркиваний, косых черт, дефисов и точек; другие символы не поддерживаются.
  • Кодер не должен URL-кодировать имя файла.
  • Кодер может включать относительные или абсолютные пути в имена файлов, хотя это не является обязательным. Если кодер включает путь в имя файла медиасегмента, он должен ссылаться на тот же путь в соответствующей записи списка воспроизведения.

Требования протокола HLS

Списки воспроизведения мультимедиа и сегменты мультимедиа, отправляемые кодировщиком, должны соответствовать спецификации HTTP Live Streaming 2nd Edition .

Спецификация HLS определяет два типа плейлистов: медиаплейлист и главный плейлист. Поскольку YouTube транскодирует потоковый контент в разные разрешения и битрейты, кодеру не нужно отправлять контент с разными битрейтами на YouTube. В результате YouTube поддерживает только медиаплейлисты для загрузки HLS, а главные плейлисты игнорируются. (Главный плейлист представляет собой набор вариантов потоков, каждый из которых описывает отдельную версию одного и того же контента.)

Кодер должен:

  • отправьте только один кодированный поток с наивысшим разрешением, который вы хотите предоставить пользователям (одно разрешение и один кодек).
  • мультиплексирование аудио и видео.
  • используйте HTTPS и постоянное соединение для всех запросов.

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

Медиа-плейлисты

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

Требования

  • Имя файла списка воспроизведения мультимедиа должно заканчиваться на .m3u8 или .m3u .

  • Первый отправленный для потока список воспроизведения медиа должен начинаться с порядкового номера 0 , а порядковый номер должен монотонно увеличиваться.

  • Тег EXT-X-MEDIA-SEQUENCE должен идентифицировать порядковый номер первого сегмента мультимедиа, указанного в списке воспроизведения.

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

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

    Обратите внимание, что сервер подтверждает получение медиасегмента, возвращая ответ 200 ( OK ) или 202 ( Accepted ) при загрузке этого сегмента. Ответ 202 означает, что сервер получил сегмент до того, как плейлист идентифицировал этот сегмент.

  • Отправляйте обновленный список воспроизведения медиа для каждого сегмента медиа, чтобы сервер мог быстро восстановиться в случае потери списка воспроизведения медиа.

  • По мере подтверждения сервером получения медиасегментов можно увеличивать значение тега EXT-X-MEDIA-SEQUENCE , чтобы предотвратить слишком длинный список воспроизведения медиа. Например, если сервер уже подтвердил получение первых девяти медиасегментов, в следующем списке воспроизведения медиа могут быть указаны восьмой, девятый и десятый медиасегменты.

  • Теги EXT-X-KEY и EXT-X-SESSION-KEY не поддерживаются.

Примеры

В следующем списке показан пример файлов, которые должен отправить кодировщик:

Media Playlist file with seqnum #0
Media Segment file #0
Media Playlist file with seqnum #0-#1
Media Segment file #1
Media Playlist file with seqnum #0-#2
Media Segment file #2
Media Playlist file with seqnum #1-#3
Media Segment file #3
...

В следующем примере показан плейлист медиафайлов, отправленный в середине прямой трансляции видео. Поскольку пример взят из середины потока, тег EXT-X-MEDIA-SEQUENCE имеет ненулевое значение.

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:4
#EXT-X-MEDIA-SEQUENCE:2680

#EXTINF:3.975,
fileSequence2680.ts
#EXTINF:3.941,
fileSequence2681.ts
#EXTINF:3.975,
fileSequence2682.ts

Медиа-сегменты

В следующем списке определены требования к медиа-сегментам:

  • Имена файлов
    • Имена файлов медиасегмента в URL-адресе должны иметь расширение .ts и должны совпадать с именами файлов в списке воспроизведения.
    • Имена файлов медиасегментов должны быть уникальными при перезагрузках кодировщика и перезапусках потока.
  • Формат
    • Медиа-сегменты должны иметь формат M2TS и быть самоинициализированными.
    • Каждый сегмент M2TS должен содержать одну программу MPEG-2.
    • Сегмент M2TS должен содержать PAT и PMT, а первые два пакета транспортного потока в сегменте должны быть PAT и PMT.
  • Содержание
    • Видео и аудио должны быть микшированы.
    • Поддерживаемые видеокодеки: H.264 и HEVC.
    • Поддерживается HDR с HEVC (см. требования HDR ).
    • Поддерживается частота кадров до 60 кадров в секунду.
    • Поддерживаются только закрытые GOP.
    • Поддерживаемый аудиокодек — AAC, поддерживается только однодорожечный звук.
    • Рекомендуемая продолжительность медиа-сегментов составляет от одной до четырёх секунд, как описано в следующем разделе. Продолжительность медиа-сегментов не должна превышать 5 секунд.
    • Медиа-сегменты должны быть зашифрованы только на уровне TLS/SSL с использованием HTTPS. Другие механизмы шифрования не поддерживаются.

Длительность медиа-сегмента

Мы ожидаем, что приём HLS будет использоваться для премиум-контента, требующего высокого качества и разрешения. Задержка при приёме HLS обычно выше, чем при приёме по протоколам RTMP и WebRTC, поскольку приём HLS основан на сегментах.

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

Битрейты

Справочный центр YouTube предоставляет рекомендации по настройке битрейта.

Обратите внимание, что HEVC обычно обеспечивает на 25–50% более эффективное сжатие данных при том же качестве видео по сравнению с H.264. Таким образом, значения битрейта в нижней части рекомендуемых диапазонов можно использовать с HEVC для экономии полосы пропускания, что особенно полезно для контента 4K.

Другие требования

  • Кодировщики должны устанавливать заголовок User-Agent в HTTP-запросе, используя следующий синтаксис, который включает название производителя, название модели и версию:

    User-Agent: <manufacturer> / <model> / <version>

Скрытые субтитры

Прием HLS поддерживает два варианта отправки скрытых субтитров:

  • Отправляйте субтитры отдельными HTTP-запросами POST. Это работает для всех типов HLS-контента.
  • Встроенные субтитры 608/708 совместимы с загрузкой HLS, использующей видеокодек H264, но не совместимы с загрузкой HEVC. Подробнее см. в разделе «Требования к субтитрам в реальном времени» в Справочном центре YouTube.

HTTP-коды ответов

В следующих разделах объясняются коды ответов, которые YouTube возвращает в ответ на медиасегменты и медиаплейлисты, доставленные с использованием HLS.

200 (ОК)

В ответ на запрос PUT или POST ответ HTTP 200 (OK) означает, что сервер YouTube получил ожидаемую операцию и успешно обработал ее.

В ответ на запрос DELETE ответ HTTP 200 (OK) означает, что сервер YouTube получил и проигнорировал запрос. Сервер YouTube не требует от клиента удаления каких-либо ресурсов в потоке и игнорирует запросы DELETE. Из соображений производительности YouTube рекомендует клиентам не отправлять запросы DELETE.

202 (Принято)

Ответ HTTP 202 (принято) означает, что сервер YouTube получил медиасегмент до получения медиаплейлиста, содержащего этот медиасегмент. Это указывает клиенту, что ему следует как можно скорее отправить медиаплейлист, содержащий этот медиасегмент, чтобы избежать задержки в обработке этого сегмента. Обратите внимание, что это не будет проблемой, если кодер будет отправлять обновлённый медиаплейлист для каждого медиасегмента.

400 (неверный запрос)

Ответ HTTP 400 (неверный запрос) указывает на возникновение одной из следующих проблем:

  • URL-адрес неверен.
  • Плейлист не может быть проанализирован или содержит неподдерживаемые теги.
401 (Неавторизованный)

Ответ HTTP 401 (Неавторизованный) означает, что параметр cid в базовом URL-адресе конечной точки YouTube HLS повреждён или устарел. Для продолжения клиенту следует обновить параметр cid .

405 (метод не разрешен)

Ответ HTTP 405 (Метод не разрешен) указывает на то, что запрос не был запросом POST, PUT или DELETE.

500 (внутренняя ошибка сервера)

Ответ HTTP 500 (Внутренняя ошибка сервера) означает, что сервер не смог обработать запрос. В случае этой ошибки мы рекомендуем повторить запрос с экспоненциальной задержкой .