В этом документе объясняется, как использовать протокол 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
В веб-интерфейсе YouTube Creator Studio после того, как автор нажмет «Создать поток», YouTube отобразит «Ключ потока», состоящий из буквенно-цифровых символов и дефисов. Этот секретный ключ идентифицирует как создателя, так и поток на YouTube.
Вы можете создать URL-адрес HLS из этого ключа потока следующим образом:
https://a.upload.youtube.com/http_upload_hls?cid=$STREAM_KEY©=0&file=
... где $STREAM_KEY
— ключ потока, отображаемый в веб-интерфейсе. Например: https://a.upload.youtube.com/http_upload_hls?cid=abcd-efgh-ijkl-mnop-qrst©=0&file=
Для большей надежности вы можете передать резервную вторую копию приема на этот резервный URL-адрес:
https://b.upload.youtube.com/http_upload_hls?cid=$STREAM_KEY©=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
и соответствовать именам файлов в списке воспроизведения. - Имена файлов медиасегментов должны быть уникальными при перезагрузке кодировщика и перезапуске потока.
- Имена файлов медиасегментов в URL-адресе должны иметь расширение
- Формат
- Медиа-сегменты должны быть в формате 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 (внутренняя ошибка сервера) указывает на то, что серверу не удалось обработать запрос. В случае этой ошибки мы рекомендуем повторить запрос с экспоненциальной отсрочкой .