（超）低延迟视频流传输的未来

作者：Anthony Dantard

翻译：Alex

技术审校：袁荣喜

▲扫描图中二维码了解音视频技术大会更多信息▲

影音探索 #013#

用户对服务的期望在不断攀升，并逐渐出现了不满情绪。由于有了YouTube和Netflix这样的视频服务，我们都希望在观看点播视频时获得超快的下载时间和流畅的播放体验。可能不太明显的是，无论我们是否意识到，这种期望都正在慢慢地向实时音频通信和直播应用转移。

在api.video，我们致力于向用户交付最佳开发和观看体验。很自然地，我们花费了大量时间思考和跟进视频协议的发展。每个视频传输协议都有其优点和缺点，并适用于不同的应用场景。

在本文中，我们总结了四种主要的低延迟协议，探讨它们的优点和缺点，并给出了我们对于这些协议未来发展的评论。下面是我们将深入讨论的四种协议：

WebRTC
LL-HLS
LL-DASH
HESP

WebRTC

WebRTC协议支持音频和视频流的实时、双向通信。它主要用于音频和视频的推流和分发，其端到端延迟在300ms~600ms之间（取决于网络质量和用户之间的距离）。WebRTC真正获得成功是在2011年，当时谷歌收购了Global IP Solutions（该公司最先开发了WebRTC），并为这个项目在资金和开发人力上提供了大量的支持。

10年之后，WebRTC已成为Web上的实时视频通信标准。通过W3C和IETF维护的JavaScript API就可以访问WebRTC组件，因此用户无需安装第三方工具即可直接通过Web浏览器进行直播。

理论上，WebRTC可以通过连接两个浏览器客户端（P2P）建立视频会议系统。然而，现实中的网络架构（互联网、公司和本地网络）会使事情变得非常复杂。

在互联网迷宫中找到自己的出路

有些时候，我们的终端并不是直接连接互联网，而是要经过几个网络层，比如NAT、防火墙或者代理。为了解决这些问题，WebRTC允许你使用ICE（Interactive Connectivity Establishment，交互连接建立）协议，该协议可以帮助你找到让两台机器通信的最直接路径，并穿过不同的网络层。为此，需要STUN/TURN服务器来获取用户的外部地址并在无法直接连接时负责通信数据转发。在大部分的WebRTC生产环境中，WebRTC协议需要（除了它自身的多媒体服务器基础设施之外）一组STUN / TURN服务器支持高质量通信。

使问题变得更复杂

WebRTC协议要求端与端之间所有通信数据必须加密（音频、视频和数据应用），因此它会内嵌一些安全协议填补使用UDP协议时的空白。WebRTC使用SDP（Session Description Protocol，会话描述协议）显示P2P连接的一些属性，如交换的媒体类型及其相关编码器、传输网络和一些带宽信息。

这其中也涉及DTLS（Datagram Transport Layer Security，数据包传输层安全协议）、SRTP（Secure Real-Time Transport，安全实时传输协议）、SCTP（Stream Control Transport Protocol，流控制传输协议），其中DTLS用于生成自签名证书来进行加密信息的协商（用于peer之间加密媒体数据以及应用数据的安全传输）。SRTP用于音频和视频的加密传输。SCTP用于应用数据的加密传输。

WebRTC规模化的挑战

WebRTC协议支持多种网络架构服务模型，每种架构对应一种特定的应用场景，而且每种架构都有自己的优劣势。本文我们不会深入讨论这些架构，但是请注意，SFU（Selective Forwarding Unit，选择性转发单元）也许是目前WebRTC应用中最流行的架构。

WebRTC所面临的主要挑战来自大规模采用的可行性（节省成本的前提下）。我们并不是说WebRTC无法在世界范围内被采用：几年以前它确实还处于规模化的早期阶段，但是一些优秀公司不懈努力地对架构进行重大的改进，已经在规模化应用方面有了很大进步。

由于WebRTC是由多个协议组成的通信标准，所以工程师们必须学习和掌握每个协议，这进一步增加了它的应用复杂度。对于大部分公司来说，在他们的基础设施中以合理成本部署全球规模的WebRTC服务还很困难。尤其是要实现支持WebRTC的各种场景，他们还需要将SFU和MCU架构混合部署在边缘节点上。

低延迟HTTP ABR流媒体传输协议

与P2P的WebRTC协议（理论上不需要中央服务器在两台机器间建立通信）相比，基于HTTP的流媒体协议需要使用服务器且在标准的HTTP上进行通信。它们构建于Web最基础的部分之上。

HLS/LL-HLS

HLS（HTTP Live Streaming）协议用于向全球范围的观众传输直播和点播内容，它于2009年由Apple推出，其特色是延迟较大的超大规模音视频分发技术。虽然用户面对的平均延迟为15秒左右，但HLS的延迟却达到了30秒~1分钟。即使在高性能的基础设施和优化的打包和播放器配置的加持下，延迟有望达到6秒，但这对于实时直播视频场景来说依然太高。不过它依然是最受欢迎的ABR流媒体协议。它的成功主要源自它对一众设备的强大兼容性，以及它可以支持多种高级功能，如隐藏字幕、广告，使用AES加密或DRM的内容保护等。虽然该协议也可以实现视频推流，但它通常用于视频的分发，一般与之配合的是使用RTMP协议进行推流。下图就是一个包括RTMP协议和HLS协议的典型直播流媒体架构。

我们不会在本文深入探讨HLS的工作原理，下图是一个简单方案：描绘了播放列表和媒体切片是如何使HLS实现码率自适应技术（ABS）的。

所以HLS如何不断发展以支持更低的延迟呢？

一开始，HLS只与MPEG-TS容器格式（与H.264/AVC编解码器相关）一起使用。在2016年，它增加了对FMP4（fragmented MP4）的支持，从而可以支持CMAF格式并与DASH兼容。一年以后，HLS增加了对H.265/HEVC（仅FMP4）的支持，显著减少了带宽的使用。因此在2020年4月，Apple终于实现了LL-HLS（低延迟HLS）——基于HLS协议的扩展；在维持HLS自身的可扩展性的同时，还可以利用子切片和这些切片的动态传输实现低延迟视频和直播。该协议的第一个草案要求支持HTTP/2 Push，但这样一来，它反而更难实现了。毫不意外，随着主流CDN厂商选择不支持此功能，LL-HLS的大规模兼容部署也进入了死胡同（因为没有CND厂商能够缓存此类内容）。不过幸运的是，Apple听取了领域和行业内的建议，又推出了新版本的扩展协议，移除了对HTTP/2 Push的需求，但保持对HTTP/2协议的依赖。他们将该标准并入HLS中，使LL-HLS能够完全向后兼容HLS，这意味着HLS的所有功能在LL-HLS中都能找到。

实际上LL-HLS的工作原理与HLS一样，但是为了降低打包过程中的延迟，它做了一些重要更改。下面是LL-HLS在保存可扩展性和ABR能力的同时，为了实现低延迟所做出的最重要的更新：

子切片（Partial Segments:）：一个切片被分割为多个子切片（或指媒体播放中几毫秒的一部分）。与原始切片在CDN上的较长“生命”相比，它们的缓存时间非常短。一旦产生完整切片，那么为了减少带宽，与其相关的子切片就会从播放列表中移除。
预加载提示（Preload hints）：媒体播放列表有一个“预加载提示”标签，它可以使播放器预知将有哪些新的子切片，以便于服务器在数据可用时立即响应播放器的新切片请求。
阻止播放列表重新加载（Block Playlist Reload）：该功能通过向请求（只有在播放列表包含一个新的切片或者子切片时，该请求才会告知服务器播放器需要响应）消息中添加查询参数避免了播放器和服务器之间的媒体播放列表轮询（Polling）。
播放列表增量更新（Playlist Delta Updates）：通过使用新的EXT-X-SKIP标签，播放器可以仅请求媒体播放列表的更新部分，从而节省已有数据的传输成本。
码率版本报告（Rendition Reports）：Primary Manifest中索引的每个版本都添加了EXT-X-RENDITION-REPORT标签，它在播放器进行ABR操作时提供了一些有用的信息，比如用于每个版本的最后一个序列号和最后一个子切片。

目前，在具备合适的GOP、子切片和合理的缓冲大小的前提下，公有云厂商所提供的端到端延迟有望达到2秒左右。虽然与WebRTC所能达到的延迟相比依然有很大差距，但在现有的直播架构中，LL-HLS显著降低了复杂性，且更加容易实现。你也可以通过修改设置将协议效用发挥到极限，达到1秒左右的延迟，但这样做的代价是牺牲播放体验的流畅性和质量。

DASH/LL-DASH

DASH是 Dynamic Adaptive Streaming over HTTP的简称，它是一种自适应流媒体传输协议。DASH于2012年4月由MPEG推出，目的是在HLS协议（由Apple拥有）之外，开发一个行业标准。它的工作原理与HLS类似：都是基于不同质量水平的内容准备，将清单文件中索引的视频切分成小块，然后再对其使用ABR技术编码。

DASH还支持通过CENC（Common Encryption standard，通用加密标准）加密的内容保护，这使它能够与所有常见DRM系统兼容。

LL-HLS和LL-DASH的主要区别是LL-DASH适用于各类编解码器。但遗憾的是，如果使用一些特殊的编码器，LL-DASH将无法与依赖iOS的Apple设备兼容（包括Apple TV）。

2017年，LL-DASH对标准化协议进行了必要的修改，将延迟降低到了2秒。背后，它所依赖的正是CMAF（Common Media Application Format，通用媒体应用格式）。CMAF使LL-DASH能够使用一些有用的HTTP特性，从而显著降低延迟。这两个特性分别是“分块编码（Chunked Encoding）”和“分块传输编码（Chunked Transfer Encoding）”，它们都是HTTP1.1的一部分（而在HTTP/2中禁止使用）。分块编码先将视频切片分割成几毫秒的视频块，这些视频块一旦被编码，就会被发送到分发层；接下来由分块传输编码将这些视频块快速分发。然而，要完成这样的传输过程，整个分发栈从源站开始一直到CDN都必须支持分块传输编码这一特性。

HESP

HESP（High Efficiency Stream Protocol，高效流媒体协议）是另一个基于ABR HTTP的流媒体传输协议，也是最新推出的协议。它是由THEOPlayer公司通过HESP联盟（主要任务是致力于HESP协议的标准化和发展）进行标准化的。

开发HESP的目的是解决其他HTTP流媒体协议的局限性，它的目标是：

在确保可扩展性（指依然可以与主流CDN厂商合作）的同时达到超低延迟（低于500毫秒）。
在传输时减少所需带宽消耗。
减少切换次数（zapping times），zapping是指各种视频流之间切换（可以想象成在观看有线电视时切换频道）的次数。

这三个性能指标对于直播观众的用户体验具有直接的影响。由于HESP的极低延迟，它也可以成为WebRTC的替代方案。HESP最主要的缺陷是，它是专有的商业协议，商用的话，价格非常高。

让我们来简单看下它的工作原理。

与其他低延迟协议相比，HESP最大的区别是它依赖两个（而非一个）视频流。在了解HESP如何帮助我们达到次秒级延迟之前，让我们先来聊聊视频流传输所使用到的不同类型的帧。在视频压缩中，要用到以下几种帧：

IDR帧（也称为关键帧）
I帧
P帧
B帧

让我们先从I帧开始，理解了I帧，你才能更好地理解其他帧。I帧包含全部图像，并且在编码时除自身外无需参考其他任何帧。

关键帧（或IDR帧）是一种特殊的I帧，关键帧之后的帧无法参考到它之前的帧。也就是说，所有IDR帧都是I帧，但反过来却不是如此。任何播放器都能使用关键帧开始播放视频。

P帧只保存当前图像与前一张图像间的变化。B帧所保存的是当前帧与其前后帧之间的变化。

现在你已经知道了构成视频的不同帧之间的作用，让我们回到组成HESP协议的视频流：

第一个视频流被称为初始流（Initialization Stream），仅包含关键帧。
第二个视频流被称为延续流（Continuation Stream），它类似于普通的编码流，意味着它能够包含所有类型的帧（取决于实现最大性能或者最大兼容的编码参数和定义的配置文件）。

初始流只用于播放开始时或者当你为了更改播放位置而滑动视频时间线时。由于它仅包含关键帧，播放器背后的解码器能够快速解码该帧，然后才开始（或重新开始）播放直播事件。一旦第一个视频流中的第一帧被获取并解码，播放器就会自动切换到第二个视频流，并继续播放视频。这是因为关键帧是完整的图像，所以它的带宽成本很高。通过切换到第二个视频流，播放器会回退到常规的实时视频流带宽占用，这将提高CDN的并发性能（CDN可以扩展观众并降低到源站的负载）。同DASH/LL-DASH一样，HESP也使用CMAF-CTE进行视频打包和分发。它继承了DASH/LL-DASH的所有的特性，比如加密、支持DRM、字幕（以及听力障碍人士所使用的字幕）、广告等。

HESP看起来很厉害（理论上），是吧？它确实解决了许多问题。但是同其他协议一样，它也不是完美的。它也有自身的缺点和局限性。第一个缺点就是，它使用两个同步编码的视频流，其编码和存储成本要高于其他基于HTTP的流媒体协议。

第二个缺点是，即使它依靠CMAF-CTE进行打包和分发，在编码和分发阶段，打包器必须进行更新才能处理两个（而非一个）视频流。

除此之外，和打包器一起，为了能够使用HESP协议播放视频并处理所有的字幕，播放器也必须进行更新。最后一点也很重要，你必须支付专利费用才能商用HESP，这无疑限制了它的普及推广。

所以哪种协议最好？

简洁的回答是没有最好的协议。这个答案似乎对做出选择没什么帮助。更完整的答案是协议的选择主要依赖于其所针对的使用场景、资源投入（包括资金和人力）、时间成本等。

如果你需要向用户和观众提供合理延迟范围内（6秒~15秒）的实时视频传输能力，同时保持成本效益，我们会推荐你使用HLS和（或）DASH，因为它们可以轻松将视频传输给数百万观众。你可以找到许多已经很好地实现了这两个协议的开源库和流媒体平台。我们更倾向于选择HLS，因为它在采用率以及浏览器和设备的支持率方面都是最高的。几乎在任何地方都可以使用它。

如果延迟对你的业务而言非常重要，你应该了解一下低延迟和超低延迟协议，如果你只需要延迟在2秒左右（适用于体育赛事、音乐会和在线课堂）的单向实时视频传输性能，而又没有太多的预算，你应该了解一下HLS和（或）LL-DASH协议。

对于其他不能接受延迟超过1秒的应用场景，你没有太多选择：WebRTC或者HESP。如果你们是一家非盈利组织，但是需要服务大量观众或者不想构建极其复杂的基础设施且没有太多预算，不妨考虑一下HESP协议。

如果你需要双向视频通信，WebRTC已经证明了它的实力。但如果构建内部基础设施并不是你的核心业务，你很可能需要依赖已经成功构建了基础设施（已实现规模化）的提供商。

最后，如果资金不是问题，我们会选择HESP，因为与实现WebRTC相比，它要简单得多，并且与各类设备和浏览器兼容。

在api.video，我们非常相信，基于HTTP的低延迟或超低延迟流媒体传输协议将在最后赢得这场“战斗”。原因非常简单，这些协议在相对陈旧的基础设施中更容易实现，并从更多设备和浏览器的支持中获益，同时它比WebRTC更容易扩展，而且由于它们并没有收取高昂的许可费用，所以大量公司都可以采用。

这就是我们基于HLS构建端到端边缘视频基础设施的原因。我们有信心，HLS在不久的未来会成为唯一满足各类音视频应用场景的传输协议。

作者简介：

CTO @api.video。api.video是一个API平台，致力于帮助开发者简化复杂的视频处理流程，并通过Web轻松创建自定义视频体验。

致谢：

本文已获得作者Anthony Dantard授权翻译和发布，特此感谢。

原文链接：

https://api.video/blog/video-trends/the-future-of-ultra-low-latency-video-streaming