Как транслировать контент на YouTube с помощью HLS

В этой статье рассказывается, как использовать протокол HLS (HTTP Live Streaming) для передачи данных в прямом эфире на YouTube с помощью видеокодера. Этот документ предназначен для поставщиков видеокодеров, которые хотят добавить в свои продукты поддержку передачи данных по протоколу HLS. Загрузка HLS – хороший вариант для премиум-контента, который требует высокого качества и высокого разрешения при относительно высокой задержке. Краткое сравнение протоколов передачи данных, поддерживаемых 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-bit 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 для загрузки, видеокодеры могут использовать YouTube Live Streaming API для вставки ресурса liveStream со следующими свойствами:

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

В ответе API поле cdn.ingestionInfo.ingestionAddress указывает основной URL загрузки, а поле cdn.ingestionInfo.backupIngestionAddress – резервный. Подробную информацию можно найти в документации по ресурсу liveStreams.

Как получить URL сервера HLS в Творческой студии YouTube

В веб-интерфейсе Творческой студии YouTube после того, как автор нажмет "Создать трансляцию", 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

Плейлисты и медиасегменты, отправляемые видеокодером, должны соответствовать спецификации HLS : потоковая передача данных по HTTP 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 передает данные сегментами.

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

Битрейт

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

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

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

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

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

Субтитры

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

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

Коды ответов HTTP

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

200 (OK)

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

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

202 (Принято)

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

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

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

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

Ответ HTTP 401 (Unauthorized) означает, что параметр cid в базовом URL конечной точки HLS YouTube поврежден или срок его действия истек. Клиенту необходимо обновить параметр cid.

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

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

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

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