本文来自THEO的行业研讨会,演讲者是THEO的CTO和创始人Pieter-Jan Speelmans。本文的主题是苹果最新推出的LL-HLS。
1
什么是HLS?
HLS发布于2009年。HLS将一个媒体文件分割为很多的小块,以供下载。HLS的下载回路就是播放器每次从服务端下载一个视频块放入缓冲区,并播放视频。
2
HLS的问题及解决方案
HLS的问题是延迟较高。因为它有很大的缓冲区,因此延迟接近四个视频段的长度。因为每个视频段都需要包含关键帧,因此不希望每个视频段的长度太短,否则可能降低QoE等指标。但是由于延迟的原因,也不希望视频段的长度太长。HLS的延迟在最低8秒到30秒之间,甚至可能达到1分半。但是在某些互动场景下8秒的延迟依然很高。
一个解决方案是LHLS媒体流,发布于2016年,延迟可达2~5秒。它使用的是HTTP1.1块传输。它会预测播放列表的下一个块,然后客户端可以开始请求它,节约了客户端寻找并下载视频块的时间。
2018年,社区试图提供低延迟HLS视频流的标准化版本,是一个重要的里程碑。当它的第一个规范版本提出时,Apple提出了LL-HLS。
3
Apple LL-HLS
与其将一个大的视频段发送,LL-HLS将其划分为多个部分。可以在播放列表的末尾添加一个部分,也可以在不被需要时丢弃。它的好处是在视频重放的时候拥有更大的视频段,而在接近时间点的时候可以选择更小的视频段。
LL-HLS的另一个变化是过去HLS会保持更新播放列表,它会向服务器发送一个播放列表请求并得到响应。它的优点是服务器是被动的,但是缺点是可能获得过时的数据。为了解决这个问题,LL-HLS引入了阻塞播放列表,并且增加了查询播放列表的参数。这些简单的机制可以显著降低延迟。
其他方面的问题在于LL-HLS仍然需要HTTP推送,CDN方面也有很多工作。CDN提供商还没有支持HTTP/2,并且有内容替换的问题。
在今年年初,APPLE提出了新版本的LL-HLS。它增加了#EXT-X-PRELOAD-HINT,取消了采用HTTP/2推流的要求。在今年四月份,APPLE更新了HLS和LL-HLS的RFC。在WWDC 2020上,Apple宣布了支持LL-HLS的平台,包括iOS 14和MacOS 11.
Apple LL-HLS为实现低延迟做了三个重要改变。
- 首先是#EXT-X-PART标签,当播放器接近生命点时,它允许将视频段分割为更加精细的粒度,这是一个很重要的改变。
- 第二个改变是播放器可以预测接下来需要哪些数据,因此#EXT-X-PRELOAD-HINT标签对于降低延迟非常重要。
- 第三个改变是可以对播放列表发出阻塞要求。
4
关于LL-DASH的问题
LL-DASH的延迟比LL-HLS要更长一些。LL-HLS拥有Apple的生态系统,到今年年底,所有的苹果设备都可以在开箱即用的情况下支持低延迟。
LL-DASH的工作原理是播放器得到一个播放清单,然后循环下载每个视频段。和社区版的低延迟HLS相似,视频会按照块传输模式发送。
LL-HLS可以将视频分割为段和部分,播放器首先获取播放列表,然后开始下载片段,一直运行直到完成下载。与此同时,它还会刷新播放列表。
5
What's next?
LL-HLS包括三个关键参数:段大小、GOP大小和部分大小。对以往的HLS而言,段大小会影响延迟。但是对LL-HLS而言,段大小不影响延迟,影响延迟的最大因素是部分大小。段大小还会影响播放列表的开销和最大GOP的大小。GOP大小的调整对QoE非常重要,它决定往视频流中插入关键帧的频率。
演讲者给出了LL-HLS的推荐参数配置,如下图所示:
6
LL-HLS应用场景
正如上文所述,预计今年九月以后,所有苹果设备将会支持LL-HLS。演讲者预计Android和HTML5也会支持LL-HLS。实际上演讲者已经创建了第一个基于安卓的播放器测试版并进行了大量的测试。
最后附上演讲视频:
http://mpvideo.qpic.cn/0bf2dmaeeaaabqaflwkglvpvag6diinqaqqa.f10002.mp4?dis_k=c21e30a85a8890f9b45ff10e8a470e17&dis_t=1598862958