通过 HLS 提交 YouTube 直播内容

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

要使用 HLS 流式传输实时数据,编码器应向 使用 HTTP PUTPOST 请求。从编码器的角度来看,YouTube HLS 端点 似乎是被动 HTTP 服务器。

每个媒体段都代表一个小片段的实际多媒体内容 持续时间为一到四秒之间各个媒体播放列表 介绍了如何按正确的视频流顺序重新组合媒体片段。

媒体格式要求

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

  • 视频和音频必须以 M2TS 格式进行多路复用。
  • 支持的视频编解码器包括 H.264 和 HEVC。
  • 支持的帧速率最高可达 60fps。
  • 仅支持闭合 GOP。
  • 支持的音频编解码器是 AAC,且仅支持单轨音频。

如需了解更详细的要求,请参阅媒体细分部分。

HDR

支持使用 HEVC 编解码器的高动态范围 (HDR) 视频, 以下额外要求:

  • 支持的颜色标准为具有非恒定亮度的 10 位 PQ 和 HLG。 更具体地说: <ph type="x-smartling-placeholder">
      </ph>
    • 色度格式必须为 YUV 4:2:0 10 位。
    • 转换函数必须为 PQ(也称为 SMPTE ST 2084)或 HLG (也称为 ARIB STD-B67)。
    • 原色必须是“建议”。2020 年。
    • 矩阵系数必须为 Rec。2020 非恒定亮度。
  • 有限范围(或 MPEG 范围)和全范围(或 JPEG 范围)样本 值。请务必根据 示例值范围。有限范围的样本值包括 建议。

获取 HLS 提取网址

通过 YouTube API 获取 HLS 提取网址

要获取完整的提取网址,编码器可以使用 YouTube 直播视频流 API插入 资源 属性:

"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 第二版 规格设计

HLS 规范定义了两种类型的播放列表:媒体播放列表和主播放列表 播放列表。由于 YouTube 将流式传输的内容转码为不同的分辨率 那么编码器就不需要将不同比特率的内容 YouTube。因此,YouTube 仅支持使用媒体播放列表进行 HLS 提取, 和主播放列表会被忽略。(主播放列表提供一组变体 视频流,其中每个视频流都描述了相同内容的不同版本)。

编码器必须:

  • 只发送一个已编码且具有您想要的最高分辨率的视频流 向用户提供(单一分辨率和编解码器)。
  • 多路复用音频和视频。
  • 对所有请求使用 HTTPS 和持久连接。

以下各部分包含针对媒体播放列表的更多具体要求 和媒体细分

媒体播放列表

媒体播放列表包含一系列媒体片段,这些片段可以连接到 表示一种可解码的连续多媒体流。媒体播放列表 服务器收到哪些媒体分段,以及如何在 重新组合的视频流

要求

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

  • 为视频流发送的第一个媒体播放列表必须从序列号开始 0 和序列号必须单调递增。

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

  • 一个媒体播放列表最多只能包含五个待处理的片段。答 如果服务器未收到或确认,则片段未完成 收到。

    除了未完成的细分之外,还包括一些已获认可的 每个媒体播放列表中的片段。这种做法可以降低 如果媒体播放列表在服务器端丢失,则要跳过的片段。对于 例如,您最多可以添加两个已确认的细分受众群, 每个媒体播放列表中的优秀片段。

    请注意,服务器通过返回 200 (OK) 或 202 (Accepted) 对上传该细分受众群的响应。答 202 响应表示服务器在 该播放列表可标识该片段

  • 每个媒体片段发送更新的媒体播放列表,以便 服务器可以快速恢复媒体播放列表。

  • 在服务器确认收到媒体片段后,您可以递增 EXT-X-MEDIA-SEQUENCE 标记值,以防止媒体播放列表变为 太长。例如,如果服务器已经确认已收到 前九个媒体片段,下一个媒体播放列表可能会列出第八个, 第 9 个和第 10 个媒体细分

  • 不支持 EXT-X-KEYEXT-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 与 HEVC 搭配使用(请参阅 HDR 要求)。
    • 支持的帧速率最高可达 60fps。
    • 仅支持闭合 GOP。
    • 支持的音频编解码器为 AAC,且仅支持单轨音频 支持。
    • 媒体片段的时长建议在一到四之间 秒,如以下部分所述。媒体片段不得 时长超过 5 秒的广告。
    • 在 TLS/SSL 层中,媒体段只能使用 HTTPS 进行加密。 不支持其他加密机制。

媒体片段时长

我们预计 HLS 提取将用于要求较高 高品质和高分辨率的图片HLS 提取的延迟时间通常比 RTMP 更长 和基于 WebRTC 的提取,因为 HLS 提取是基于片段的。

我们建议将媒体片段时长设为 1 到 4 秒 较小的媒体片段可以缩短延迟时间,但代价是 重新缓冲速率并降低编码效率。如上一部分所述, 媒体片段的时长不得超过 5 秒。

比特率

YouTube 帮助 中心 提供了码率设置准则

请注意,在相同的环境下,HEVC 通常可使数据压缩率 视频质量(与 H.264 相比)。因此, 可以将建议的范围与 HEVC 结合使用,以节省带宽, 非常实用

其他要求

  • 编码器应使用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(错误请求)响应表示存在以下某个问题 发生时间:

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

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

405(不允许的方法)

HTTP 405(不允许的方法)响应表明请求 而不是 POST、PUT 或 DELETE 请求。

500(内部服务器错误)

HTTP 500(内部服务器错误)响应表明服务器 无法处理此请求。对于此错误,我们建议您重试 请求指数 退避时间