Discover HLS Blocking Preload Hints

Highlight

Low-Latency HLS 要求 playlist 发布 #EXT-X-PRELOAD-HINT，让客户端提前请求下一个 Partial Segment，服务器在分片可用时立即返回，从而减少发现媒体后的额外往返延迟。

核心内容

直播的低延迟瓶颈常常藏在一个很小的空档里：playlist 更新后，客户端才知道新分片的 URI，然后再发起媒体请求。跨地区 CDN 场景下，边缘节点到源站的一次往返可能超过 100 毫秒。对目标延迟只有几秒的直播来说，这个空档会反复累积。

Blocking Playlist Reload 已经解决了 playlist 发现问题。客户端可以提前请求下一个 playlist 版本，服务器等 playlist 更新后再返回。Blocking Preload Hints 把同一套思路用到媒体分片本身：playlist 先写出下一个 Partial Segment 的提示，客户端立即请求这个 URL，服务器等分片编码和打包完成后返回数据。

结果是媒体不再等到“看见新分片”以后才开始请求。客户端通常会同时挂着一个 Blocking Playlist Reload 请求和一个 preload hint 请求。新 Partial Segment 完成时，服务器更新 playlist，也释放媒体请求。播放器拿到 playlist 更新时，媒体数据已经在路上。

这场 Session 还解释了两种交付模型。简单模型里，每个 Partial Segment 有独立 URL。CMAF Chunk 模型里，多个 Partial Segment 是同一个 parent segment 的 byte-range，客户端可以用 chunked transfer 从一个请求中连续收取多个 chunk。这让同一套媒体更容易同时服务 Low-Latency HLS 和 Low-Latency DASH。

详细内容

提前请求下一个 Partial Segment

（00:48）Preload hinting 的目标，是在媒体真正可用前就建立请求。playlist 必须带上 #EXT-X-PRELOAD-HINT，其 URI 指向 packager 预计将要生成的下一个 Partial Segment。

已发布的最后一个 Partial Segment：part1.1.m4s
Preload Hint 指向 packager 预计生成的下一个 Partial Segment：part1.2

关键点：

• transcript 明确给出最后一个已发布 part 是 part1.1.m4s。
• transcript 明确说明 hint 告诉客户端下一个可以尝试加载的 part 是 part1.2。
• TYPE=PART 是 preload hint 用于媒体 Partial Segment 的语义。
• 客户端看到 hint 后立即请求 hinted URL；如果分片还没生成，服务器保持请求，等分片可用后返回。

（02:30）实际请求流很直接。客户端先发起 Blocking Playlist Reload，随后发起 hinted Partial Segment 请求。编码器完成新 Partial Segment 后，服务器同时释放媒体响应并更新 playlist。播放器省掉了“收到 playlist 后再请求媒体”的一轮等待。

给 MAP 做提示，提前处理内容切换

（02:15）Preload hints 也可以提示即将出现的 MAP。这对广告边界这类内容切换很重要，因为播放器可以提前获取新的初始化信息，减少切换处的停顿。

内容切换前：playlist 可以提示即将出现的 MAP。
内容切换后：playlist 继续提示下一个 Partial Segment。

关键点：

• transcript 说明 preload hints 可用于 upcoming MAP tags。
• MAP hint 的目的，是让客户端提前准备内容切换所需的初始化信息。
• 内容边界处，客户端仍然会继续加载后续 Partial Segment。
• 如果广告素材是预录内容，服务器可以立即返回 hint 请求，不需要像实时编码内容那样阻塞等待。

用 byte-range 表达 Partial Segment

（03:39）Partial Segment 不一定有独立文件。它也可以是较大资源中的 byte-range。Preload Hint tag 可以带上 BYTERANGE-START 和 BYTERANGE-LENGTH。当长度尚未确定时，可以只写起始位置。

Preload Hint 可以提示 segment 23 中从 0 开始、长度为 4,044 字节的范围。
如果长度尚未确定，hint 只保留 byte-range 的起始位置。

关键点：

• transcript 明确举例说明 hint 可以指向 segment 23 的 0 到 4,044 范围。
• byte-range 起始位置告诉客户端下一个 Partial Segment 从 parent segment 的哪个位置开始。
• byte-range 长度告诉客户端当前已知的范围大小。
• 如果 packager 发布 hint 时还不知道长度，可以省略长度。

用 CMAF Chunk 和 chunked transfer 连续交付

（04:17）CMAF Chunk 可以映射成 Low-Latency HLS 的 Partial Segment。服务端把多个 chunk 逐步追加到同一个 parent segment，客户端对 parent segment 发起一个开放式请求，通过 Chunk Transfer Encoding 连续接收后续 Partial Segment。

第一个更新：segment 1 的第一个 Partial Segment 是前 3,000 字节，hint 更新为从 3,000 开始。
第二个更新：segment 1 出现第二个 byte-range，hint 更新为从 8,000 开始。

关键点：

• transcript 明确说明第一个 Partial Segment 是 segment 1 的前 3,000 字节。
• 下一次 playlist 更新后，hint 的起始位置更新到 3,000。
• 再下一次更新后，第二个 part 出现，hint 指向下一个 part 的起始位置 8,000。
• Session 特别提醒，很多 CDN 不支持直播内容的 Chunk Transfer Encoding；采用这个模型前必须验证 CDN 能力。

允许服务器改变计划

（07:42）Preload Hint 是计划，不是承诺。服务器发布 hint 后仍然可以改变下一段内容，常见场景是运营方决定提前从广告返回直播。

服务器已经发布一个 hint。
运营方决定提前从广告返回直播。
下一次 playlist 更新没有包含之前 hinted URL。
客户端取消挂起的 hint 请求，改用 playlist 中真实出现的内容。

关键点：

• transcript 说明服务器发布 Preload Hint 后仍然可以改变计划。
• 常见原因是运营方决定提前从广告返回直播。
• 下一次 playlist 更新时，如果之前 hinted URL 没有出现在 playlist 中，客户端会取消挂起请求。
• 客户端随后加载 playlist 中真实出现的新 Partial Segment。

核心启发

• 做低延迟直播的请求时序仪表盘：把 Blocking Playlist Reload、preload hint 请求、Partial Segment 返回时间画在同一条时间线上。为什么值得做：Session 强调这两个阻塞请求通常会同时挂起并接近同时返回。怎么开始：在播放器和边缘服务日志中记录 playlist 请求、hint 请求、HTTP unblock 时间和 part URI，再按 #EXT-X-PRELOAD-HINT 对齐。

• 做 HLS packager 的 hint 一致性检查：验证每个 hinted URL 是否会在后续 playlist 中作为 #EXT-X-PART 或 #EXT-X-MAP 出现。为什么值得做：服务器可以改变计划，但普通错误会让客户端请求无效资源。怎么开始：解析连续 playlist 快照，追踪 #EXT-X-PRELOAD-HINT，在下一次更新中确认 URI 和 byte-range 是否匹配。

• 做 CDN 能力探测工具：检测目标 CDN 是否支持直播场景的 Chunk Transfer Encoding。为什么值得做：CMAF Chunk 方案可以复用同一套媒体服务 Low-Latency HLS 和 Low-Latency DASH，但 Session 明确提醒许多 CDN 不支持这种直播交付方式。怎么开始：向测试 parent segment 发起长连接请求，服务端逐步追加 chunk，客户端记录是否能分批收到数据。

• 做广告边界预加载验证：专门测试 TYPE=MAP 和 TYPE=PART 在广告插入、提前回切直播时的行为。为什么值得做：Session 提到 MAP hint 可帮助内容切换，也说明服务器可能在广告中途改变计划。怎么开始：准备包含直播、广告、提前返回三类 playlist 更新的测试流，检查播放器是否取消旧 hint 并加载新分片。

关联 Session

• What’s new in Low-Latency HLS — 先了解 Low-Latency HLS 的整体协议扩展，再看 preload hinting 的细节。
• Optimize live streams with HLS Playlist Delta Updates — 大播放窗口会让 playlist 变长，Delta Updates 解决的是 playlist 传输效率问题。
• Reduce latency with HLS Blocking Playlist Reload — Blocking Playlist Reload 负责提前等待 playlist 更新，是 Blocking Preload Hints 的配套机制。
• Adapt ad insertion to Low-Latency HLS — 广告插入会触发 MAP 和 Partial Segment 的内容切换，适合和本 Session 一起看。
• Improve stream authoring with HLS Tools — HLS Tools 可用于检查 authoring 输出，帮助验证 LL-HLS playlist 结构。