ALHLS：Apple低延迟HLS技术

在WWDC 2019上，Roger Pantos宣布了Apple针对HLS的最新规范，其变化旨在减少实时视频流的延迟。本文来自Mux流媒体专家Phil Cluff，LiveVideoStack进行了翻译。

文 / Phil Cluff

翻译 / John

原文 

https://mux.com/blog/the-community-gave-us-low-latency-live-streaming-then-apple-took-it-away/

在WWDC 2019上，Apple 依照惯例宣布了一系列的软件更新。并且像过去4年的传统一样，Roger Pantos上台宣布了HTTP直播视频流（HLS）规范的最新变化，今年的变化旨在减少实时视频流的延迟，但这样做的代价是什么呢？

HLS是一种分段传输技术，支持向设备进行实时和点播视频流传输。虽然HLS是为苹果设备设计的，但现在也已经被广泛应用于视频流生态系统，包括浏览器、智能电视、机顶盒和游戏机。HLS是一个易于理解和实现的简单协议，开发者可以提供一个主播放列表（通常称为清单）文本文件，该文件描述了可用内容的不同分辨率和码率组合，开发者可以为每种组合提供单独的播放列表，此列表包含媒体片段、持续时间以及获取它们的URL。

虽然HLS具有简单、易扩展等优势，但当被用于实时流式传输时，很容易出现高延迟问题。关于这点，我们将重点讨论“wall-clock”或者“glass-to-glass”延迟，即从发生IRL事件开始到被终端用户看到之前的时间。

在HLS中，延迟与正在使用的媒体片段的持续时间密切相关。通常情况下，提供可接受的流媒体体验使用的片段持续时间最低界限为2s，这种情况下产生的延迟大约为10秒；而使用更长持续时间的片段设置的传统HLS流，延迟可能会达到30秒以上。

在今年的WWDC上，Pantos宣布Apple更新了HLS，加入了新的低延迟模式。有趣的是，这不是第一次尝试着为低延迟HLS编写规范。基于两年多之前发布的白皮书，视频开发者社区使用的低延迟HLS开发规范也已经有一年多的时间了。表面上使用视频开发者社区的方法更简单，同时可部署更广泛且高可用的技术。那么为什么Apple没有使用视频开发者社区的解决方案呢？让我们来看看Apple所采取的方法与其它社区一直在做的工作有何不同。

Apple的低延迟HLS（ALHLS）

首先，让我们看看Apple的低延迟HLS解决方案是如何工作的。你可以在这里观看演示并阅读说明。

（https://developer.apple.com/videos/play/wwdc2019/502/） 

1. 媒体分片

ALHLS会以持续时间为250-300ms的TS或CMAF块的形式，生成部分媒体的分片片段。其中包含几个完整的视频或音频帧，但这可能不包括完整的GOP（图像组或一组序列独立的视频帧），Apple将这些称为“部件”。

Apple已经为HLS播放列表格式引入了一种新排列方式，旨在允许这些部件被公布在实时HLS播放列表的顶部并允许客户端下载它们。这意味着在编码器输出数据之后，播放器可以更快地获得较小的帧组，而不是花费2到10秒的时间以等待帧准备就绪之后再下载它们。

有趣的是，根据规范，一旦这些部件处于“可被全速下载”的状态，它们必须且只会被添加至播放列表中。至于为什么会这样，我们会在后文对其进一步探索。

2. 推送分片

在最基本的层面，HLS依赖于通过轮询播放列表文件来检查新的可用段，结束一次轮询之后是另一个用以检索新片段的HTTP往返。而当需要低延迟传送时，这些传统HTTP请求的开支将成为决定“Well-Clock”延迟下限的重要条件。

Apple解决此问题的新方法是，使用HTTP/2推送那些在播放列表请求响应中较短的媒体“部件”。然而，这也意味着按照Apple的新方法，播放列表必须要被非常频繁地取出，其频率具体取决于目标延迟和部件持续时间，可能高达每秒3-4次。

3. 阻止播放列表请求

Apple添加的新功能之一是一种允许播放列表的HTTP请求保留一段时间，直到特定的片段或部分可用的模式。例如：播放一段内容的片段“20”，客户端可以再次请求播放列表以进行片段的再现；而一旦片段“21”可用，那么播放器仅需“21”的响应即可播放片段。这样做是为了如果播放器未能在前一个播放列表到达之后立即发出请求，播放器可以被允许以最短的时间请求新的播放列表（新的媒体片段）。

此功能与接下来的两项功能都依赖于Apple在HLS中引入的一个新客户端——服务器通信。Apple保留了所有查询参数，_HLS从新的“Origin API”开始就可以被用于操纵播放列表生成的行为。

4.  播放列表增量更新

HLS的一项令人头疼的问题是播放列表的臃肿与代价。对于包括大型实时倒带窗口的长时间运动流，再现播放列表中的段列表可能需要非常漫长且复杂的工作；即使使用gzip，每次再现HLS播放列表也会轻易得到数十万字节或更多的数据。而如果每隔几百毫秒就下载一个播放列表，那么其背后庞大且臃肿的数据处理量将成为一个棘手的问题。

为解决此项通病，Apple在本次HLS更新中启用了一种可生成“delta”播放列表的方法，该方式允许段列表仅包含完整播放列表中的某些段；玩家一次请求完整的播放列表，此时播放列表的内部状态将维持不变，较小的增量播放列表会被添加至播放列表中。这种仅包含若干最新片段与播放列表顶部多个文件的的增量播放列表与播放列表头部的低延迟“部件”将一起组成新的播放列表以供用户选择。

我必须说，此项功能深得我心; 此解决方案经过深思熟虑，真正解决了HLS长期存在的问题。我希望Apple会将此功能应用在无低延迟要求的链路当中，因为播放列表的臃肿是一个亟待解决的问题。

5. 更快的码率转换

最后，Apple引入了一个小功能，允许特定节目的播放列表响应包含有关最新块和可用于另一个节目片段的信息——理论上这允许播放器跳转到另一个节目，无需请求制作完成的播放列表就能立即启动切换。

从概念上讲，这是一个很好的功能；但是现在的(ALHLS规范的当前版本似乎缺少足够的细节使其可以被可靠地用在实际工作流程中（并且Apple公开的Demo版本实际上并不支持此功能）。值得注意的是，此功能似乎并非旨在允许播放器直接从一个节目跳转到另一个多媒体文件的某个片段，而是通过请求阻止播放列表更新来优化播放列表请求，并利用HTTP/2推送尽可能获取部件与该请求。

我认为通过更多的思考和设计，此方案可能非常有用，特别是如果(ALHLS还有一种方法可以在播放列表响应中推送CMAF流的初始化段，将会极大增加它的可用性。

如果你之前使用过HLS，那么讲到这里你也许会觉得ALHLS有如此多的可调节组件，事实上的确如此。ALHLS是对HLS这一非常简单的规范所设计的相当复杂的补充。为了从中获益，开发者将不得不实现所有功能，包括一些我没有提到的（如HTTP/2等）功能以实现符合预期的低延迟HLS流。至少在目前，开发者必须让基于ALHLS实现的应用程序进入应用程序商店，经过苹果的审核之后才能发布。苹果会使用特殊标识符来标记这些应用程序清单。

这些变化使得ALHLS相对于传统HLS方法的最大不同是ALHLS需要更多建立在播放列表生成过程和编码器编码过程之间的数据交换。从经验上来看，此过程并不复杂：编码器生成一个新片段并将其放入某个存储（CDN或对象存储），同时更新播放列表以指示新段可用。而现在，生成播放列表时ALHLS必须执行更多逻辑，包括在某些情况下，当组件处于可被下载状态时挂起连接一段时间。

在我看来，ALHLS并不是一个糟糕的规范。尽管ALHLS非常复杂且包含众多可调整的组件，但这并不会影响其功能与优势。

一些保留或使用查询参数来改变播放列表生成行为的解决方案并非我喜欢的方法，阻塞播放列表请求行为也是不可取的，而ALHLS也面临诸多挑战。

ALHLS实施面临挑战

查询参数用法

2019年的大多数播放列表请求都将查询参数作为其内容安全机制的一部分，这意味着对播放列表的所有URL中的一部分进行签名可阻止未经身份验证的用户访问内容。而向URL引入新的功能性查询参数会为播放列表请求的签名和缓存实现增加额外的复杂性，同时也为第三方播放器开发引入了新的挑战。

阻止播放列表重新加载

阻止播放列表请求肯定会让整个系统变得难以维护，并且对于当前记录的超时现象至今仍无法得到合理解释与有效解决方案。（在目标持续时间的3倍之后503）。除此之外，此策略会给开发者带来一系列值得关注的针对Web和CDN的安全性与性能问题。

HTTP/2服务器大规模推送

众所周知的是，采用Apple解决方案的的最大挑战是强制使用HTTP/2。在公告中，Apple称HTTP/2会“被CDN广泛采用”。虽然从表面上看这是事实，但这种说法并不适用于Apple要求开发者所使用的一系列HTTP/2功能。

HTTP/2服务器推送主要通过允许服务器（在这种情况下是CDN中的节点）将对象推回客户端而非客户端主动请求来实现功能。如果我们希望通过主流CDN实现大规模应用，则需面临以下两个主要问题：

1. HTTP/2 推送在许多CDN上未能实现。虽然通用HTTP/2在主流厂商的CDN上具有较高的覆盖率，但推送的实施程度却很低。如果开发者希望实施大规模流媒体服务，其应该考虑的最重要因素之一就是采用 多CDN策略 ，但这的确不是一个好方案。

一般通过在原始响应里的Link 标头中预装的关键字来实现HTTP/2推送。这会导致CDN将其缓存中的两个对象链接在一起并在合适的时机推送，但这也会为我们带来新的问题……

2. 由于开发者现在必须实现将媒体与播放列表响应一起推送，因此开发者现在必须为播放列表请求和媒体请求使用相同的边缘端点。因为HLS明确支持媒体段的绝对URL，这与以往的经验不同。

对于许多供应商来说，这将是一个巨大的麻烦。由于不同厂商的需求各异，供应商花费数年时间建立了系统并分离播放列表和媒体交付过程，播放列表是小文本文件，可以进行gzip压缩并频繁更改；而媒体段则是大型二进制块，一旦创建就永远不会更改。播放列表快速且易于生成，而媒体片段则远没有那么容易。

视频开发者社区低延迟HLS解决方案（LHLS）

现在让我们来谈谈ALHLS与视频开发者社区的LHLS解决方案有何不同。

HLS.js与包括Mux、JW Player、Wowza、Elemental和Akamai在内的各大企业一起合作开发出了LHLS这一解决方案并在过去一年多的时间探索使用HLS实现低延迟流媒体，关于正式标准的讨论请参阅以下网站：Github问题 。LHLS最初的概念与术语来自2017年中期发布的Periscope博客文章，此文章描述了他们如何自主实现低延迟HLS流。你可以在这里阅读这篇文章。 

这种方法实际上非常简单（比ALHLS简单得多）。除了一些简单的新播放列表语义之外，LHLS使用与提供低延迟MPEG DASH-HTTP 1.1分块传输编码相同的策略。分块传输编码适用于此，因为分块传输编码允许开发者在完整响应可用之前开始将HTTP响应作为数据块发送。

这是一项十分有用的成果，因为分块编码允许系统在编码器生成视频片段的同时发送Apple正在调用视频片段的“部件”，在此之后返回到客户端。播放器可以在获得这些“部件”之后立即开始播放而无需等待完整分片可用。分块传输模式的真正好处在于，其可以在绝大多数CDN上使用，这也意味着分块传输比现在的HTTP/2推送拥有更广泛的支持。

除了更加出色的可用性之外，与ALHLS相比，LHLS实际上允许一些轻度操作在客户端设备上被执行。从表面上看，LHLS遵循传统的HLS范例、轮询播放列表更新与片段抓取；但由于LHLS能够在片段编码时将片段轮回，开发者实际上不必重新加载经常播放的播放列表；而在ALHLS，开发者仍需以每秒多次的频率轮询播放列表从而寻找可供使用的新部件，即使这些新部件会在清单请求之后被推送给开发者。

如果Apple将ALHLS（主要是delta播放列表）的一些概念带到LHLS，那将是一件非常棒的事情——集二者之所长，我们会得到一个完美而强大的HLS解决方案。

那Apple为什么不参与社区呢？

如果LHLS如此出色并在视频开发者社区中得到支持，为什么Apple不参与呢？这一问题的答案我们不得而知。苹果公司决定忽视已有的社区或标准并不是一件新鲜的事情，但苹果公司在过去几年内已经表示他们已开始与视频流媒体行业的其他企业保持一致。

尽管Apple在过去几年从未采用MPEG DASH流媒体标准（尽管MPEG DASH参与了DASH行业论坛，但其依旧是HLS的竞争标准），但Apple已经开始支持fMP4和CMAF媒体块。这种支持现在已经应用于绝大多数Apple设备，这意味着以一种方式（包括低延迟模式）为一种终端提供一组媒体段的梦想终于开始逐渐成为现实。

然而，随着DASH对低延迟流媒体的LHLS风格分块传输交付的持续标准化，现在看来Apple正通过强化ALHLS的应用，迫使我们回到封闭的交付堆栈策略。

对于许多HLS和视频平台供应商来说，最大的挑战是强制性的HTTP/2推送，但我也强烈怀疑这就是Apple选择让所有开发者都按照他们期待的方向前进的关键。ALHLS和LHLS共同面临的一大挑战是带宽估计问题，为了提供出色的流媒体体验，开发者必须准确衡量并响应用户带宽的变化。从以往经验上来说，估计用户的可用带宽非常简单——开发者可以测量最后一个媒体段下载的时间长度并检查该段的大小，通过一系列简单的数学计算得到带宽估算结果。

然而在分块传输世界中，当开发者期望每个分片完全下载的时间与生成下载所花费的时间一样时，估计带宽并不是一件容易的事情。开发者需要测量备用带宽的性能，同时提取播放列表或使用小参考文件，偶尔也需使用完整段或其他内容。

我从工作中得到的经验是，Apple不想以上述任何麻烦的方式解决此问题，只留下允许AVPlayer（Apple的流式传输框架）能够测量分块传输响应的各个块的性能。我怀疑Apple为了支持HTTP/2，它们决定不在设备上添加任何新功能到遗留的HTTP 1.1堆栈。

而现在来看，HTTP/2推送绝对不能有效解决此项问题。在现代浏览器或设备中，没有允许开发者检查HTTP/2推送响应的下载性能的API。而阻止播放列表请求会让情况变得更糟：测量阻塞播放列表提取的性能以及段加载无法得到准确的测量结果，也无法将播放列表下载性能用作代理。我们必须假设Apple有一种方法可以在使用HTTP/2时，在自己的设备上测量下载性能，原因如下：

1. 这是Apple实现让低延迟策略与自适应码律一起工作的唯一方式，并且......

2. 相关内容在Apple的规范中被提及： 

“在将部分片段添加到播放列表时，它必须以与客户端链接的全速下载。”

当然，还有一种看待苹果如此策略的观点是“经典的Apple策略”。虽然这些决定确实倾向于植根更多的物理硬件，但这并不意味着这是Apple第一次表达对于现有成熟技术的强烈反对意见——耳机插孔、USB-A、物理HOME按键……苹果提出这样的策略似乎已经见怪不怪。要知道苹果是加密狗的最忠实支持者，或许在未来我们可以得到从ALHLS到LHLS的加密狗。

非Apple设备支持ALHLS

Apple的低延迟测试版目前仅与iOS设备兼容——即使MacOS上最新的Safari技术预览也不支持ALHLS。但是，Apple设备实际上只是HLS生态系统的一小部分。

值得关注的是，支持HLS的非Apple规模庞大，例如经由HLS.js和Video.js这样的HLS播放套件实现的视频流播放，每天的规模高达数十亿次。因此，让我们假设视频行业改变过去一两年中一直追求的方法，只是遵循Apple的规范。

如果真是如此，那么ALHLS在现代浏览器或其他设备上易于实现吗？恐怕并非完全如此。Apple选择的技术（即HTTP/2）使得非Apple设备很难实现ALHLS，包括HLS.js，在自己的网站上用它来制作自己的开发者视频。

HTTP/2是一项年轻的技术，使用它的工具非常有限，同时浏览器中的Web API也不够成熟，无法在现有应用之上构建低延迟流技术。由于Apple可以利用私有API，因此很可能Apple最终能够在Safari中实现良好的HTTP/2支持，但是为了支持和调试ALHLS的第三方应用，其他浏览器可能必须迅速作出改变。

那么，我们该何去何从？

显然，我们确信Apple针对ALHLS与LHLS已经进行了大量调研。但是，在Apple的ALHLS规范准备就绪完成实现之前，还需应对并解决一些重大的挑战。

视频流媒体行业的客户都渴望获得低延迟解决方案，以便他们可以与Twitch或Twitter / Periscope等对手竞争。社区的LHLS策略是真实存在并可实现的，同样也没有什么可以阻止您在所有主流浏览器中以向后兼容的方式实现它。

然而，甚至是在iOS上，Apple的ALHLS显然还需要几个月的时间才能正式上线，最早也要到iOS13才有可能出现，考虑到主流CDN上HTTP/2推送的有限可用性，使用单边主机名的要求以及Apple对ALHLS新应用的审核与验证，我们不太可能在近期看到ALHLS的大规模部署。如果您希望在桌面或其他Web播放器上基于ALHLS获得相同技术的相似体验，那么您还必须等待Web播放器可支持更复杂的ALHLS部署。这使得供应商和客户面临更大的挑战。供应商是继续推进基于分块传输的解决方案LHLS，还是全面支持Apple新提出的ALHLS？市场会在不久之后给我们这一问题的答案。

公平的说，业内很多人对Apple的ALHLS规范反响热烈，但忽视社区开发的选项，同时推行过度面向未来的方法并不是什么好的方式。在某些情况下，比如Swift方面，Apple正在成为一个更加以社区为中心的组织。

LiveVideoStack  招募

LiveVideoStack正在招募编辑/记者/运营，与全球顶尖多媒及技术专家和LiveVideoStack年轻的伙伴一起，推动多媒体技术生态发展。了解岗位信息请在BOSS直聘上搜索“LiveVideoStack”，或通过微信“Tony_Bao_”与主编包研交流。

扫描图中二维码，即刻了解更多大会讲师及分享内容信息！