通过 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 直播 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 服务器收到了预期操作并已成功处理。

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

202（已接受）

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

400 (Bad Request)

HTTP 400 (Bad Request) 响应表示发生了以下问题之一：

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

HTTP 401 (Unauthorized) 响应表示 YouTube HLS 端点的基础网址中的 cid 参数已损坏或过期。客户端应更新 cid 参数才能继续。

405 (Method Not Allowed)

HTTP 405 (Method Not Allowed) 响应表示该请求不是 POST、PUT 或 DELETE 请求。

500 (Internal Server Error)

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