通过 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 标记值，以防止媒体播放列表过长。例如，如果服务器已确认收到前九个媒体片段，则下一个媒体播放列表可能会列出第八、第九和第十个媒体片段。

  • 不支持 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。
    • 支持采用 HEVC 的 HDR（请参阅 HDR 要求）。
    • 支持的帧速率最高为 60fps。
    • 仅支持闭合 GOP。
    • 支持的音频编解码器为 AAC，并且仅支持单轨道音频。
    • 建议媒体片段的时长介于 1 秒到 4 秒之间，如以下部分所述。媒体片段的时长不得超过 5 秒。
    • 媒体片段只能在 TLS/SSL 层中通过 HTTPS 进行加密。 不支持其他加密机制。

媒体片段时长

我们预计 HLS 提取将用于需要高质量和高分辨率的优质内容。HLS 推流通常比基于 RTMP 和 WebRTC 的推流延迟时间更长，因为 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 服务器已收到预期操作并成功处理。

如果 YouTube 服务器收到并忽略了 DELETE 请求，则会返回 HTTP 200 (OK) 响应。YouTube 服务器不要求客户端删除流中的任何资源，并且会忽略 DELETE 请求。出于性能方面的原因，YouTube 建议客户端不要发送 DELETE 请求。

202（已接受）

HTTP 202 (Accepted) 响应表示 YouTube 服务器在收到包含相应媒体段的媒体播放列表之前收到了该媒体段。这会向客户端表明，它应尽快发送包含相应媒体片段的媒体播放列表，以防止该片段的处理出现延迟。请注意，如果编码器为每个媒体段发送更新后的媒体播放列表，则不会出现此问题。

400 (Bad Request)

HTTP 400（错误请求）响应表示发生了以下问题之一：

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

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

405（不允许使用的方法）

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

500（内部服务器错误）

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