WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
What's new in Low-Latency HLS

What's new in Low-Latency HLS

HLSLow-LatencyStreaming
观看原视频

Highlight

Apple 将 Low-Latency HLS 从 beta 推向 iOS 14、tvOS 14 和 macOS，并用 Blocking Preload Hints 替换 HTTP/2 Push，让低延迟直播保留 HLS 的码率切换、FairPlay、fMP4 CMAF 和 CDN 扩展能力。

核心内容

做直播视频时，延迟通常来自一个朴素的问题：客户端要等新媒体片段出现，服务端和 CDN 要把它送到边缘节点，播放器再开始请求。2019 年的 Low-Latency HLS 已经给出方向，但它依赖 HTTP/2 Push 把新片段随播放列表更新推给客户端。Apple 在这一年收到的反馈很明确：很多内容分发链路不适合 Push，广告支持的内容尤其难接入。

这场 session 的重点，是把 Low-Latency HLS 变成可部署的协议。它在 2020 年结束 beta，进入 iOS 14、tvOS 14 和当年的 macOS。原来需要特殊资格的实验能力，变成 native app 可直接使用的 HLS 能力，并且继续支持码率切换、FairPlay Streaming、fMP4 CMAF 等已有特性。

协议层面的关键改变，是用 Blocking Preload Hints 取代 HTTP/2 Push。客户端提前请求下一个 part，服务端等到内容准备好再返回。请求由客户端发起，CDN 边缘节点能顺手触发 cache fill，不需要边缘节点和源站之间再为 Push 付出额外往返。对直播平台来说，这个变化把低延迟能力放回常见 CDN 模型里。

Apple 还同步收紧了 playlist 更新模型。Rendition Reports 不再通过按需指令单独选择，改为每次 playlist update 都携带，避免相同更新生成大量不同 URL。Delta Updates 可以携带最新的 date-range tag，长 DVR 窗口和密集元数据不必重复传输整份列表。Part 和 Rendition Report 新增 gap signaling，客户端能更好处理编码中断。

详细内容

Low-Latency HLS 结束 beta

（00:17）Roger Pantos 开场先给出部署结论：Low-Latency HLS 结束 beta，并在 iOS 14、tvOS 14 和当年的 macOS 可用。它属于 HLS 协议的一组低延迟扩展，目标是在两秒以内的 stream delay 下继续使用 HLS 生态，而非替换现有播放器栈。

Low-Latency HLS availability
- iOS 14
- tvOS 14
- macOS in 2020

Supported HLS features
- bit-rate switching
- FairPlay Streaming
- fMP4 CMAF
- native application playback
- no entitlement required

关键点：

  • iOS 14、tvOS 14、macOS in 2020 是本场演讲明确列出的可用平台。
  • bit-rate switching 表示低延迟直播仍然保留多码率自适应能力。
  • FairPlay Streaming 说明受保护内容不用放弃 DRM（数字版权管理）。
  • fMP4 CMAF 让内容生产链路可以继续使用碎片化 MP4 和 CMAF（Common Media Application Format）。
  • no entitlement required 把 2019 年的试用门槛移除，普通 native app 可以接入。

规范进入 HLS RFC 草案

（00:45）Low-Latency HLS 的规则被加入 ietf.org 上的 HLS RFC 第二版修订草案。Apple 还补充了两个附录：Low-Latency Server Configuration Profile 和 CDN tune-in algorithm。开发者不再需要只看临时 beta 页面，而是可以按 HLS 规范和 Apple 的 authoring spec 检查设备支持。

HLS RFC second revision draft
- Low-Latency protocol rules
- Low-Latency Server Configuration Profile appendix
- CDN tune-in algorithm appendix

Apple developer documentation
- HLS authoring specification
- Apple device support information

关键点：

  • Low-Latency protocol rules 进入 HLS RFC 草案，代表这些规则成为核心 HLS 规范的一部分。
  • Server Configuration Profile 面向服务端配置，帮助 origin、packager 和 CDN 按同一套约束工作。
  • CDN tune-in algorithm 说明客户端进入直播流时如何和 CDN 协作，降低起播路径中的等待。
  • HLS authoring specification 是检查 Apple 设备支持范围的入口。

Blocking Preload Hints 替换 HTTP/2 Push

（01:41）原始低延迟设计为了减少 segment delay，使用 HTTP/2 Push 把新 segment 跟 playlist update 一起送出。反馈显示，Push 不适合很多内容分发方式，也不适合不少广告支持的流。新的做法叫 Blocking Preload Hints：客户端提前请求下一个 part，服务端等它可用后返回。

Old delivery path
1. Server creates a new segment.
2. Playlist update becomes available.
3. HTTP/2 Push sends the segment with that playlist update.

Updated delivery path
1. Client asks for the next part before it is ready.
2. Server holds the request.
3. Server responds when the part is ready.
4. The client-driven request triggers CDN cache fill.

关键点：

  • Old delivery path 依赖 HTTP/2 Push，要求 CDN 和服务端链路支持 Push 行为。
  • Client asks for the next part before it is ready 是 Blocking Preload Hints 的核心动作。
  • Server holds the request 对应 blocking 行为，服务端不立即返回空结果。
  • triggers CDN cache fill 是 Apple 强调的 CDN 友好点，请求从客户端发出后，边缘节点可以自然填充缓存。
  • 演讲仍要求 CDN 支持 HTTP/2，但不再要求 CDN 支持 Push。

Rendition Reports 改为随 playlist update 下发

（03:13）CDN 团队反馈，客户端如果可以请求特定 rendition report，同一个 playlist update 会对应大量不同 URL。URL 组合变多，缓存命中率就下降。Apple 删除 report delivery directive，改为每个 playlist update 都携带全部 Rendition Reports。

Before
playlist update + requested rendition report set
=> many URLs for the same update
=> lower CDN cache efficiency

Now
playlist update
=> all Rendition Reports included
=> one cacheable update shape

关键点：

  • requested rendition report set 是旧方案造成 URL 组合膨胀的来源。
  • many URLs for the same update 会让 CDN 把同一份更新当成多份对象缓存。
  • all Rendition Reports included 牺牲少量响应体大小，换来更稳定的缓存形状。
  • 这个改动直接服务于大规模直播的 CDN 效率。

Delta Updates 支持 date-range tag

（03:40）很多直播流会有长 DVR 窗口，还会频繁使用 date-range tags 表示节目、广告或事件元数据。完整 playlist 会越来越长。Apple 为 Playlist Delta Updates 加入 date-range tag 的处理方式，使更新只携带最近的 date-range tag。

Long DVR playlist
- old media segments
- current media segments
- many date-range tags

Playlist Delta Update
- recent playlist changes
- the most recent date-range tag

关键点：

  • Long DVR playlist 描述长回看窗口下的完整播放列表。
  • many date-range tags 是元数据密集流的常见负担。
  • Playlist Delta Update 只传增量，减少客户端和 CDN 重复传输。
  • the most recent date-range tag 来自本场演讲的改动，解决 date-range 元数据在增量更新里的携带问题。

gap signaling 覆盖 Part 和 Rendition Report

（04:00）低延迟直播对编码中断更敏感。Apple 在 Part 和 Rendition Report tags 上增加新的属性，用 gap signaling 表示流中存在缺口。客户端可以根据这些信号跳过不可用内容，减少卡在缺失片段上的风险。

Gap signaling targets
- Part tags
- Rendition Report tags

Client behavior enabled by the signal
- detect encoded outages
- avoid waiting on unavailable low-latency parts
- continue recovery using rendition information

关键点：

  • Part tags 对应低延迟流中的 partial segment 层级。
  • Rendition Report tags 对应不同 rendition 之间的同步信息。
  • encoded outages 是演讲中明确提到的故障场景。
  • continue recovery using rendition information 说明 gap signal 的价值在客户端恢复路径，而不是只记录错误。

HLS 工具链和参考服务器更新

（04:17）Apple 更新了 Low-Latency server reference implementation。去年那套工具可以生成低延迟流；2020 年版本增加 fragmented MPEG-4 packaging，使输出兼容 CMAF。Web server 设置也简化了：过去要配置自己的 web server 再接 PHP script，现在可以运行一个 Go script，同时实现 delivery directives 和 HTTP/2 web server。

Updated Low-Latency HLS tools
- fragmented MPEG-4 packaging for CMAF compatibility
- Go script for delivery directives
- HTTP/2 web server in the same package
- included in the regular HLS tools download

关键点：

  • fragmented MPEG-4 packaging 对应演讲中 late 2019 加入的选项。
  • CMAF compatibility 让同一份媒体包装更容易进入标准化分发链路。
  • Go script 减少本地搭建参考服务器的步骤。
  • delivery directives 和 HTTP/2 web server 放在同一包内，方便开发者复现实验流。
  • regular HLS tools download 表示低延迟工具回归统一下载入口。

核心启发

  1. 做一个低延迟体育直播播放器

    • 做什么：把比分、弹幕或实时统计叠加在直播画面旁边，让画面和互动数据保持接近同步。
    • 为什么值得做：Low-Latency HLS 目标是两秒以内的 stream delay，且保留 bit-rate switching 和 FairPlay Streaming。
    • 怎么开始：先用 HLS tools 生成低延迟流，再在播放器侧验证 iOS 14、tvOS 14 和 macOS 的播放路径。

  2. 做一个 CDN 回源效率监控面板

    • 做什么：监控 playlist update、Rendition Reports、part 请求和 CDN cache fill 的命中情况。
    • 为什么值得做：Blocking Preload Hints 改为客户端发起请求，Apple 明确指出它能触发 CDN cache fill。
    • 怎么开始：在 origin 和 CDN 日志中按 playlist update、part URI、rendition 维度聚合请求，重点观察同一更新是否产生过多 URL 变体。

  3. 做一个长 DVR 直播元数据验证工具

    • 做什么：检查长回看窗口里的 date-range tags 是否能通过 Playlist Delta Updates 只传最近变化。
    • 为什么值得做：演讲提到大量 date-range tags 会影响长 DVR 窗口，2020 年协议为 Delta Updates 加入了相关处理。
    • 怎么开始：用 HLS playlist 解析器读取完整 playlist 和 delta playlist，确认最近的 date-range tag 出现在增量更新里。

  4. 做一个低延迟流故障恢复测试流

    • 做什么：人为制造编码缺口，观察播放器是否能根据 Part 和 Rendition Report 的 gap signaling 继续播放。
    • 为什么值得做：Apple 在 Part 和 Rendition Report tags 上加入 gap signaling，用来处理 encoded outages。
    • 怎么开始：准备多 rendition 直播流，在部分输出中制造缺口，再记录播放器等待、切换和恢复时间。

  5. 做一个低延迟 HLS 本地实验环境

    • 做什么：用更新后的 HLS tools 快速搭建一套本地 origin，生成 fMP4 CMAF 兼容的低延迟流。
    • 为什么值得做：参考实现已经把 delivery directives 和 HTTP/2 web server 合并到 Go script，搭建成本低于旧版 PHP 方案。
    • 怎么开始：下载常规 HLS tools 包，使用其中的低延迟工具生成 fragmented MPEG-4 内容，再通过参考 server 测试客户端请求节奏。

关联 Session

评论

GitHub Issues · utterances