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

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

Внимание: этот метод получения URL-адресов приема HLS является бета-функцией и может измениться в будущем.

В веб-интерфейсе 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 (ОК) указывает на то, что сервер YouTube получил ожидаемую операцию и успешно ее обработал.

В ответ на запрос DELETE ответ HTTP 200 (ОК) указывает, что сервер YouTube получил и проигнорировал запрос. Сервер YouTube не требует от клиента УДАЛИТЬ какой-либо ресурс в потоке и игнорирует запросы DELETE. Из соображений производительности YouTube рекомендует клиентам не отправлять команды DELETE.

202 (Принято)

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

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

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

• URL-адрес имеет неверный формат
• Список воспроизведения не может быть проанализирован или содержит неподдерживаемые теги.

401 (Несанкционированный)

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

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

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

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

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