下载客户端

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

2022-06-20 15:16

来源：澎湃新闻·澎湃号·湃客

作者：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 在不久的未来会成为唯一满足各类音视频应用场景的传输协议。

作者简介：