LL-HLS的演进

本文来自THEO网站的博客文章，原标题为LL-HLS Series: The Evloution of LL-HLS。主要内容为讨论低延迟HLS系列。

HTTP实时流媒体，也就是HLS，是苹果为了解决扩展问题在2009年发布的。HLS协议目前成为非常流行的协议并且被广泛应用。和其他基于HTTP的流媒体协议一样，它的最大缺点是延迟。本文讨论了低延迟HLS的出现，变量如何变化，更新如何随时间改变，和它们如何影响流媒体传输。

01

更低延迟的需求

尽管HLS被广泛应用，但是延迟成为日渐严重的问题，会带来糟糕的体验。工业界开始提出一些对抗延迟的策略，并积极寻找更低延迟视频交付的办法。Twitter’s Periscope平台首先提出了一系列改进并在2016年提出LHLS。Periscope提出的是专利的版本，它旨在提供2~5秒的延迟并确实解决了HLS的一些问题。该协议可以和HLS标准兼容，因此跨平台的播放器可以恢复到标准HLS。LHLS提出了两个方法来降低延迟：

1、 利用HTTP/1.1分块传输进行片段

2、 在片段可用之前声明片段

尽管减少片段的大小是另一个可行的方法，但是它有诸多限制。在一个最佳的场景中，每个片段起始于I帧，这让播放器可以迅速开始播放一个片段，而不用等待和下载一个更早的片段。因为I帧比P帧大很多，因此减少片段大小并增加I帧数目，将提升总体利用的带宽。

Periscope使用的方法解决了大缓冲区的问题，因为该缓冲区的一部分预先声明了，但是不可用。因此，这实际上减少了实时点的强制退避，也减少了建立缓冲的能力。因此播放器需要迅速知道一个分块的位置。通过预期分块的创建和已经列出的未来分块的位置，一个播放器可以预测哪个文件需要被导入。尽早声明这些片段可以让不使用LHLS的播放器像正常的HLS流一样播放，并且改善延迟。

这个更新消除了通过分割视频流引入的延迟和播放列表引入的延迟。此外该方法可支持CDN，因为它们支持HTTP/1.1分块传输。

02

工业界的回答

根据Periscope在LHLS方面取得的进展，大批公司开始尝试分块传输和HLS的组合。在此基础上起草了基于社区的L-HLS规范。虽然它和Periscope的LHLS基于相同的概念，但是它为未来的片段引入了新标签，而不是替换播放列表中的最后一个片段。这样可以消除和L-HLS规范不兼容的播放器的影响，并且使这些播放器可以构建和普通HLS一样的大缓冲区。

Apple在2019年发布了低延迟HLS，也就是LL-HLS。该扩展仍提供与常规HLS的向后兼容性，但是提供了Apple认可的方法来降低HLS的延迟。不了解该协议扩展的播放器将以较高延迟播放相同的流。这使得发布者可以为优化和非优化播放器提供单一的HLS解决方案。从本质上说，该更新很简单：允许片段分为更小的部分，也可以构建为更大的片段下载。

LL-HLS的首个版本的最大挑战是HTTP/2的推送要求。随着协议扩展公告的发布，Apple表示CDN将广泛采用此要求，但是实际并非如此。新的协议扩展需要许多HTTP/2功能，包括多流控制，H2推送和H2 ping。然而许多主要的CDN并未做好准备，这使得大型可扩展性仍然是工业界面对的问题。

工业界感觉Apple错过了使用分块传输编码（CTE）的简单解决方案。使用基于CTE的解决方案将简化在HLS和MPEG-DASH流上交付低延迟内容的过程。该扩展也意味着实施的延迟。对于SSAI，该规范要求播放列表操控器和CDN之间密切合作。将播放列表生成和数据交付结合在一起，将需要CDN提供程序采用新的算法和可伸缩性策略。

03

最新的LL-HLS更新

2020年初，Apple宣布对LL-HLS规范草案进行更新。在业界关心和摩擦之后，此更新删除了HTTP/2 Push要求，而是引入了一个新标签来宣布即将出现的片段。此更新使LL-HLS协议与低延迟L-HLS的社区版本非常相似。

新提出的标签称为#EXT-X-PRELOAD-HINT。借助此标签，发布低延迟HLS流的服务器可以宣布继续播放所需的下一个媒体数据的最可能位置。这允许播放器客户端执行请求，从而允许数据段的下一部分可用时立即流入。然后可以重复此过程，从而在加载新媒体数据时可以消除额外的往返时间（也是使用HTTP/2 push的主要原因）。

更新的规范要求对已经开始实施LL-HLS工具的人员（包括THEO）进行重大更改。但是，新更改带来的优势对于行业而言意义重大，并且将消除HTTP /2推送采用的障碍，从而简化技术的部署。4月底，Apple发布了HLS的更新的RFC，包括LL-HLS，这使得将来不太可能进行较大的更改。这使行业可以全力以赴地使用LL-HLS，而不必冒对体系结构进行重大更改的风险。

LL-HLS规范的其他重要更新包括：

1、新标签的使用已和正常HLS流一起指定使用。这意味着其中某些功能也可以在没有低延迟模式的情况下使用（即支持阻止播放列表重载和增量播放列表的功能）。

2、新增加的CAN-SKIP-DATERANGES标签允许跳过日期范围的标签。

3、定义了一个LL-HLS配置文件。它包含了LL-HLS初步规范中的大多数数据：不再需要阻止播放列表重新加载；可以为同一类型列出多个预加载提示；不再定义部分必须在播放列表中保留多长时间。

04

当下采用的LL-HLS

最新的LL-HLS更新通过简化与当前市场上主要的替代性低延迟解决方案（例如LL-DASH和社区L-HLS）的兼容性提供了另一个优势。实际上，新的LL-HLS规范就像是L-HLS的超集，该规范还利用标签来宣布下一个分段的位置。尽管如此，该行业正在放弃社区L-HLS，并且已经开始向前发展并采用Apple LL-HLS规范的最新更新。随着Apple最近巩固了从HLS规范的初步扩展到正式更新的变化，业界对此进行投入是安全的。

05

接下来是什么？

本文讨论了HLS，LHLS和LL-HLS在过去十年中的发展和变化。接下来会更深入地了解最新规范的工作原理，已解决的问题，规范带来的挑战和机遇。THEO当前有一个beta播放器可用，它支持最新的LL-HLS更新。

附上原文链接：

https://www.theoplayer.com/blog/evolution-of-ll-hls