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

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

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

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

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

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

  • Видео и аудио должны быть мультиплексированы в формате 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-адрес приема, кодировщики могут использовать YouTube Live Streaming API для вставки ресурса 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 определяет два типа списков воспроизведения: Media Playlist и Master Playlist. Поскольку 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. Дополнительную информацию см. в требованиях к Live Caption в Справочном центре YouTube.

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

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

200 (ОК)

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

В ответ на запрос DELETE ответ HTTP 200 (ОК) означает, что сервер YouTube получил и проигнорировал запрос. Сервер YouTube не требует от клиента УДАЛИТЬ какой-либо ресурс в потоке и игнорирует запросы УДАЛЕНИЯ. Из соображений производительности 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 (внутренняя ошибка сервера) означает, что сервер не смог обработать запрос. В случае этой ошибки мы рекомендуем повторить запрос с экспоненциальной задержкой .