8e28abd60e4d15521832d634bbceb000
WWDC20 10231 - 使用 Blocking Playlist Reload 降低 HLS 延迟

本文基于 Session 10231 - Reduce latency with HLS Blocking Playlist Reload

概览

Blocking Playlist Reload 是低延迟 HLS 必需的一个组件,它帮助改善了 HLS 直播媒体流中 Segment 的发现时间。本 Session 将介绍如何使用 Blocking Playlist Reload 技术来减少直播流的延迟以及改善 LL-HLS 和常规 HLS 中 CDN 缓存的性能问题。

什么是 Blocking Playlist Reload

在 HLS 的基本策略中,客户端通过不断地刷新 Playlist 发现新的 Segments。但在原本的技术方案上,客户端会在每个 Target Duration 结束时尝试刷新 Playlist,请求新的 Segment。这样的策略虽然简单有效,但在某些较坏的情况下会导致 HLS 很高的延迟(WWDC19 中 低延迟 HLS 介绍 有提到此问题)——如果客户端在某个 Target Duration 结束时刚好错过了 Playlist 的更新,那么它必须要等到下一个 Target Duration 结束才可以成功获取到最新的 Playlist,也就造成了 HLS 的延迟问题。

而在低延迟 HLS 技术中,我们已经了解到了客户端可以通过在 GET 请求中附带某些具体参数来调用服务端都某些具体服务,那么如果把此功能应用到 Blocking Playlist Reload 上面,我们可以让客户端告知服务端此次请求需要在 Playlist 增量更新前刮起。服务端则会在 Playlist 更新后马上结束挂起,并把最新结果返回给客户端。

细节

可选性

Blocking Playlist Reload 是一项可选的功能,因此服务端需要让客户端知道对此功能的支持,通过在 tag 中加入 CAN-BLOCK-RELOAD=YES 属性来标明支持此功能。

首次加载 Playlist

客户端首次请求 Playlist 时,无需附带 Blocking Playlist Reload 相关的任何参数字段,此时服务端只需要返回当前最新的 Playlist。

重新加载 Playlist

每次客户端需要更新 Playlist,或者在首次加载 Playlist 完成后,客户端都需要发出一次 Playlist Reload 请求,此次请求会带上 _HSL_msn 参数来指定获取第一个新的 Segment。同时,如果当前的 Playlist 是一个低延迟 Playlist 的话,客户端也会指定下一个新的 Partial Segment。服务端在收到此次请求后会暂时挂起请求,直到 playlist 更新且满足要求。

具体流程图解

接下来,我们以图解的方式解析一下整个流程的具体步骤。

客户端请求更新

在下面的例子中,假设客户端请求 Partial Segment 2,但服务端还没有此 Partial Segment,那么服务端会暂时挂起此次请求。

客户端请求 Partial Segment 2

客户端请求 Partial Segment 2

服务端响应更新

在一段时间过后,服务端完成了对 Partial Segment 2 的编码和处理工作,并且成功加入了当前 Playlist,此时服务端会取消挂起并立即返回最新结果给客户端。

服务端响应 Partial Segment 2

服务端响应 Partial Segment 2

一个实际中的例子

普通的 HLS

普通 HLS Playlist

普通 HLS Playlist

上图中表示的是一个普通的 HLS Playlist,我们可以留意到:

  • 此 playlist 设置了 CAN-BLOCK-RELOAD=YES,即开启了 Blocking Playlist Reload 功能。
  • 第一个 Segment 是媒体序列号为 19 的 m4s 文件。
  • 最后一个 Segment 是媒体序列号为 23 的 m4s 文件,也就是说下一个新的 Segment 将会是序列号为 24 的媒体文件。

因此,当客户端请求 Playlist 更新时,将会带上 _HLS_msn = 24 的参数,以此指定需要的下一个最新 Segment:

```

top Created with Sketch.