通过 HLS 提交 YouTube 直播内容

本文档介绍了如何使用 HTTP Live Streaming (HLS) 协议通过编码器在 YouTube 上流式传输实时数据。本文档面向希望为其产品添加 HLS 提取支持的编码器供应商。对于需要高画质和高分辨率但延迟时间相对较长的优质内容，HLS 提取是理想之选。如需简要比较 YouTube 直播支持的不同提取协议，请参阅 YouTube 直播提取协议比较。

如需使用 HLS 流式传输实时数据，编码器应使用 HTTP PUT 或 POST 请求将一系列媒体播放列表和媒体片段发送到 YouTube 的 HLS 端点。从编码器的角度来看，YouTube HLS 端点似乎是被动 HTTP 服务器。

每个媒体片段代表直播中一段时长介于 1 到 4 秒之间的实际多媒体内容。每个媒体播放列表都介绍了如何按正确的串流顺序重新组合媒体片段。

媒体格式要求

YouTube HLS 提取对视频和音频内容有以下要求：

  • 视频和音频必须采用 M2TS 格式进行混合。
  • 支持的视频编解码器为 H.264 和 HEVC。
  • 支持高达 60fps 的帧速率。
  • 仅支持闭合 GOP。
  • 支持的音频编解码器为 AAC，且仅支持单轨音频。

如需了解更详细的要求，请参阅媒体细分受众群部分。

HDR

使用 HEVC 编解码器支持高动态范围 (HDR) 视频，并且具有以下额外要求：

  • 支持的颜色标准包括 10 位 PQ 和 HLG（亮度不恒定）。具体而言：
    • 色度格式必须为 YUV 4:2:0 10 位。
    • 转换函数必须为 PQ（也称为 SMPTE ST 2084）或 HLG（也称为 ARIB STD-B67）。
    • 原色必须为 Rec. 2020。
    • 矩阵系数必须为 Rec. 2020 非恒定亮度。
  • 支持有限范围（或 MPEG 范围）和全范围（或 JPEG 范围）的采样值。请务必根据内容使用的示例值范围设置范围。建议使用范围有限的示例值。

获取 HLS 提取网址

从 YouTube API 获取 HLS 提取网址

如需获取完整的提取网址，编码器可以使用 YouTube Live Streaming API 插入具有以下属性的 liveStream 资源：

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

在 API 响应中，cdn.ingestionInfo.ingestionAddress 字段指定主要提取网址，cdn.ingestionInfo.backupIngestionAddress 字段指定备用提取网址。如需了解详情，请参阅 liveStreams 资源的文档。

从 YouTube 创作者工作室获取 HLS 提取网址

在 YouTube 创作者工作室网页界面中，创作者点击“创建直播”后，YouTube 会显示一个由字母数字和连字符组成的“直播码”。此密钥用于标识创作者和 YouTube 直播。

您可以根据此直播键构建 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=

为了提高可靠性，您可以将提取内容的冗余第二个副本传输到此备用网址：

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

请注意，备用网址与主网址有两个不同之处：主机名和 copy= 参数都已更改。备用提取必须发送与主要提取不同的 copy= 参数值，以免损坏数据流。

填写 HLS 提取网址

使用上述任一方法获得的网址都是不完整的模板；每个网址都以空的 file= 查询参数结尾。如需构成最终到达网址，编码器必须将媒体播放列表或媒体片段的文件名附加到网址的末尾，从而完成 file= 参数。

以下规则适用于 file= 参数的值：

  • 编码器可以使用字母数字字符、下划线、正斜线、连字符和英文句点构建媒体播放列表或媒体片段文件名；不支持使用任何其他字符。
  • 编码器不得对文件名进行网址编码。
  • 编码器可以在文件名中包含相对路径或绝对路径组件，但这并不是必需的。如果编码器在媒体片段文件名中包含路径组件，则必须在相应的播放列表条目中引用相同的路径。

HLS 协议要求

编码器发送的媒体播放列表和媒体片段必须符合 HTTP Live Streaming 第 2 版规范。

HLS 规范定义了两种类型的播放列表：媒体播放列表和主播放列表。由于 YouTube 会将流式传输的内容转码为不同的分辨率和比特率，因此编码器无需向 YouTube 发送不同比特率的内容。因此，YouTube 仅支持将媒体播放列表提取为 HLS，并会忽略主播放列表。（主播放列表提供一组变体串流，每个变体串流都描述同一内容的不同版本。）

编码器必须：

  • 仅发送一个编码流，且分辨率为您要向用户提供的最高分辨率（单一分辨率和编解码器）。
  • 对音频和视频进行混合。
  • 对所有请求使用 HTTPS 和持久连接。

以下部分包含有关媒体播放列表和媒体片段的更具体要求。

媒体播放列表

媒体播放列表包含一个媒体片段列表，这些媒体片段可以串联起来表示可解码的连续多媒体流。媒体播放列表会告知服务器应预期哪些媒体片段，以及如何在重新组合的串流中正确排列这些片段。

要求

  • 媒体播放列表文件名必须以 .m3u8 或 .m3u 结尾。

  • 为数据流发送的第一个媒体播放列表必须从序列号 0 开始，并且序列号必须单调递增。

  • EXT-X-MEDIA-SEQUENCE 标记必须标识播放列表中列出的第一个媒体片段的序列号。

  • 媒体播放列表中的未播放片段不得超过 5 个。如果服务器尚未收到某个分段或未确认收到该分段，则该分段处于待处理状态。

    除了待处理的片段之外，还应在每个媒体播放列表中添加一些已确认的片段。这样做可以降低在服务器端丢失媒体播放列表时跳过片段的可能性。例如，您最多可以在每个媒体播放列表中添加两个已确认的片段和最多五个待处理的片段。

    请注意，服务器会在上传媒体片段时返回 200 (OK) 或 202 (Accepted) 响应，以确认收到该媒体片段。202 响应表示服务器在收到标识该片段的播放列表之前收到了该片段。

  • 为每个媒体片段发送更新后的媒体播放列表，以便在媒体播放列表丢失时，服务器可以快速恢复。

  • 当服务器确认收到媒体片段时，您可以递增 EXT-X-MEDIA-SEQUENCE 标记值，以防止媒体播放列表过长。例如，如果服务器已确认收到前 9 个媒体片段，则下一个媒体播放列表可能会列出第 8、第 9 和第 10 个媒体片段。

  • 不支持 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

媒体片段

以下列表列出了媒体细分的要求：

  • 文件名
    • 网址中的媒体片段文件名必须带有 .ts 文件名扩展名，并且必须与播放列表中的文件名一致。
    • 在编码器重新启动和数据流重启期间，媒体片段文件名必须是唯一的。
  • 格式
    • 媒体片段必须采用 M2TS 格式，并且应自行初始化。
    • 每个 M2TS 片段都必须包含单个 MPEG-2 节目。
    • M2TS 片段必须包含 PAT 和 PMT，并且片段中的前两个传输流数据包应为 PAT 和 PMT。
  • 内容
    • 必须对视频和音频进行混音。
    • 支持的视频编解码器为 H.264 和 HEVC。
    • 支持 HDR with HEVC（请参阅 HDR 要求）。
    • 支持高达 60fps 的帧速率。
    • 仅支持闭合 GOP。
    • 支持的音频编解码器为 AAC，并且仅支持单轨音频。
    • 建议媒体片段的持续时间介于 1 到 4 秒之间，如以下部分所述。媒体片段的时长不得超过 5 秒。
    • 媒体片段只能在 TLS/SSL 层中使用 HTTPS 加密。不支持其他加密机制。

媒体片段时长

我们希望 HLS 提取功能适用于需要高质量和高分辨率的高级内容。与基于 RTMP 和 WebRTC 的提取相比，HLS 提取的延迟时间通常较长，因为 HLS 提取是基于分段的。

我们建议将媒体片段时长设置为 1 到 4 秒，因为媒体片段越小，延迟时间就越短，但代价是重新缓冲率更高，编码效率更低。如上一部分所述，媒体片段时长不得超过 5 秒。

比特率

YouTube 帮助中心提供了有关比特率设置的准则。

请注意，与 H.264 相比，在相同视频质量下，HEVC 通常可实现 25% 到 50% 的数据压缩率。因此，建议的范围下限的码率值可与 HEVC 搭配使用，以节省带宽，这对 4K 内容尤为有用。

其他要求

  • 编码器应使用以下语法在 HTTP 请求中设置 User-Agent 标头，其中包含制造商的名称、型号名称和版本：

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

字幕

HLS 提取支持两种字幕发送方式：

  • 使用单独的 HTTP POST 请求发送字幕。这适用于所有 HLS 提取内容。
  • 嵌入式 608/708 字幕适用于使用 H264 视频编解码器的 HLS 提取内容，但不适用于使用 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（已接受）响应表示 YouTube 服务器在收到包含该媒体片段的媒体播放列表之前收到了该媒体片段。这会指示客户端应尽快发送包含该媒体片段的媒体播放列表，以免该片段的处理出现延迟。请注意，如果编码器为每个媒体片段发送更新后的媒体播放列表，则不会出现此问题。

400 (Bad Request)

HTTP 400（Bad Request）响应表示出现了以下问题之一：

  • 网址格式不正确
  • 播放列表无法解析或包含不受支持的标记
401 (Unauthorized)

HTTP 401（未经授权）响应表示 YouTube HLS 端点基本网址中的 cid 参数已损坏或已过期。客户端应更新 cid 参数才能继续操作。

405（不允许使用的方法）

HTTP 405（不允许使用的方法）响应表示请求不是 POST、PUT 或 DELETE 请求。

500 (Internal Server Error)

HTTP 500（内部服务器错误）响应表示服务器无法处理请求。对于此错误，我们建议您使用指数退避算法重试请求。