低延迟视频直播是2018年的热门话题之一。本文通过多个实际用例详细介绍了不同场景下，影响用户体验的延迟范围，降低延迟的策略并探索可以为用户提供最佳体验的不断发展的技术。本文来自Mux客，LiveVideoStack进行了翻译。感谢 Hulu Senior Dev Lead 傅德良提供的审校支持。

文 / Phil Cluff

译 / 元宝

审校 / 傅德良

原文

https://mux/blog/the-low-latency-live-streaming-landscape-in-2019/

在过去的2018年，良好性能的低延迟视频直播一致成为NAB、IBC和Demuxed等公司努力的方向。接下来我们将借助多个实例探讨研究直播延迟如何影响用户体验，并探索能够推动视频直播产品进一步发展的新技术。

在深入研究视频直播延迟之前，我们需要明确延迟的定义：我们可以把延迟理解为用户观看视频直播时直播端呈现画面与现实中主播端记录下画面并非同步所出现的时间线偏差。常见类型有端到端延迟、镜头-显示屏延迟等

延迟在什么时候很重要？

延迟的故事很复杂。延迟的可接受程度完全取决于您要解决的问题。我们将下面的一些用例放在一起，我们认为这些用例通常会对最终用户感受到的延迟产生挑战。

语音和实时通信

基于实时通信的应用场景更易受到延迟的影响，例如以个人视频电话为例的一对一在线交流或以视频会议为例的团队在线沟通。

通常情况下对于实时通信而言，200ms（0.2秒）的延迟就会为通信体验带来明显不良影响；而超过200ms的延迟会使实时通信变得难以继续进行，与此同时延迟不单单会为双方交流的实时性带来障碍，随着延迟增加逐渐恶化的噪声与回声也使技术界对低延迟的研究越来越迫切。

当实时通信的延迟高达一秒以上，用户的实时交流就失去了存在的意义。因此业界在设计相关协议与技术指标时会通过适当降低画面质量的方式做出一定妥协，从而确保能够在极端环境下也能提供基本的实时通信服务。

例子：

• FaceTime
• Google Meet / Hangouts
• Skype

体育和电子竞技

体育赛事直播面临的挑战并非尽可能实现最低延迟，而是实现多端同步延迟。我们知道现在的大型体育赛事直播都是通过广播电视网络与卫星通信等传统技术手段实现传输。对于许多广播电视公司来说其目标在于让身处不同传输链路（互联网、广播、有线电视、数字电视等）的所有用户体验到同步的延迟，一般延迟为2秒～15秒之间，广播的平均延迟约为6秒。需要强调的是这种几秒甚至几十秒的延迟并非技术缺陷而是人为规定，其主要用于广播电视的监管机构能够在直播画面制作完成到播出之间进行审查。

而对于那些关注度较高的大型体育赛事直播而言，其关键点在于实现两种传递策略（互联网与广播电视）下的视频直播画面的延迟同步，从而能够将视频画面同时呈现给不同端观众。例如在上届世界杯，当英国队进行点球大战时你可以在不同时期听到来自伦敦市中心不同酒吧派对的英格兰球迷的欢呼声，其原因便是在互俩网端BBC iPlayer上的超高清视频流比有线电视晚播出20-30秒，这种不同播放渠道之间高达半分钟的延迟对当时期待进球结果的球迷而言无疑是对比赛精彩悬念的毁灭，也会让广播电视公司的服务水平大打折扣。所以在英国，一般情况下周四晚通过互联网视频流在Twitch上播出的球赛会比普通的有线电视广播提前20秒左右播放。

电子竞技面临的延迟问题则更为有趣，与体育赛事直播不同是，电子竞技直播一般不需要广播电视等传统媒体传输渠道实现视频流传输，其对延迟的敏感程度也低于其他传统体育赛事直播场景。随着社交网络与新闻供应商不断改善画面延迟，观众对延迟的要求越来越高，相信没有人愿意在互联网浏览视频时被突然出现的延迟推送打扰。

例子：

• 体育：BBC iPlayer或Fubo上的FIFA世界杯
• 电子竞技：Twitch上的DOTA “The Internationals”

交互式体验和交互式UGC流

随着UGC直播文化的发展，我们可以很清晰地发现视频直播所涉及的应用面不再局限于体育产业与电子竞技，而是拓展成为一个渗透生活多个方面的全方位流媒体平台。与Twitch上的视频产品普遍强化交互元素不同，UGC直播将特定流媒体用户社区之间的沟通交流聊天互动作为主要产品导向。

我们在Twitch的朋友长期以来一直是低延迟实时流媒体技术领域的践行者，为降低平台流媒体延迟做出了卓越贡献，降低极端情况下的视频延迟至几秒钟。

我们尝试进一步推进良好互动直播体验的持续深入拓展。过去几年我们喜闻乐见的程序之一是HQ Trivia，其背后测试过程的艰辛与最终良好直播同步功能的实现使其整个开发过程都令人难忘。由于无法有效获得信号参考点，我们很难精准衡量HQ Trivia的端到端延迟水平，但仅通过在直播现场观察演示者与他人的聊天的回应情况，我们依旧能够非常容易地视其仅在很少的几秒钟发生极端延迟现象。HQ Trivia最令人印象深刻同样也是其成功的关键便是在多种设备与网络除了在拍卖领域的应用，专为彩行业建立的直播流媒体服务也成为当下众多彩公司竞相部署的热点。去年我们看到很多彩公司开始与线下庄家建立针对二十一点、轮盘或扑克等轻量级彩活动的流媒体平台。这些用于彩的视频流的有效性也基于能够确保庄家与众多玩家互动的实时性与同步性。

例子：

• 拍卖：苏富比拍卖行
• 视频场：BetOnline

低延迟权衡

我们在为用户设计直播类产品时需要始终明确，必要时为了保证产品服务的实时性可以采取一定妥协与牺牲措施。例如从视频成为互联网内容的一部分开始我们就使用预缓冲内容的方式尽可能降低不利网络条件对用户观看视频体验的影响，而实际上任何减少延迟的尝试都会导致玩家缓冲内容数量的降低，从而使得最终的用户体验变得更加糟糕。

在过去的十年里，视频行业一直尝试优化自适应比特率技术（ABR）。此方法通过使流适应用户的可用带宽来改善观众的最终用户体验，其原理是评估观众在播放器请求一段视频时的带宽情况并分析用户观看下一段内容时匹配哪种视频质量最佳。在理想环境下此方法非常有效，随着模型不断降低延迟与延迟的减少，其同样会引入一些问题。

传统上，为了缓解直播流的延迟，我们会减少观众收到每个视频块持续的时间。然而，这不仅意味着需要减少了播放器缓冲流的持续时间，而且还意味着观众必须更频繁地请求视频块，与此同时不断增加的HTTP请求也会带来额外开销。

即便最终降低延迟的目标得以实现时，ABR技术的有效性也是伴有一定牺牲的。如客户端持续缓冲视频流的时间一旦过长，回放时就会出现 数据包丢失，网络更改或缓存未命中的弹性就越大。不幸的是，我们看到的一些以低延迟名义销售的技术也减少了冗余备份，增加了复杂性，并引入了大量的供应商锁定。

减少延迟的方法

一般来说，三种主要的方法开始成为减少实时流技术领域内延迟的常用策略。我们将在下面讨论这三种方法，并尝试将它们分别应用到我们在上面识别的案例中。

采用短视频分片长度

• 延迟： 30到10秒之间
• 用例：市面上大部分直播，大多数运动和一些电子竞技
• 适应性：高
• 支持并发量：大

正如我们之前讨论的那样，减少ABR驱动流的延迟的传统方法是减少传递给最终用户的分片持续时间。在过去几年中，根据苹果公司HLS规范的更新建议，平均分片长度从大约10秒减少到大约6秒。更短的分片通常会导致更低的延迟，原因是大多数播放器都是在开始播放之前预先缓冲一定数量的分片。例如，iOS设备和Safari上的嵌入式视频播放器总是在开始播放之前缓冲三个视频分片。每个分片的持续时间为2秒（大致是可行的最小时间）的三个分片意味着约6秒的最小延迟，这里不考虑摄取，转码，打包和传送媒体分片所花费的时间。

DASH协议稍微改进了这种标准，允许manifest文件指定在播放开始之前需要缓冲多少流。这包含在minBufferTime属性中。不幸的是，在现实世界中，只有个别DASH播放器和设备实现了这种策略，并且许多人在开始播放之前会继续下载一定数量的分片。这在“智能电视”或客厅设备上尤为常见。

实时协议

• 延迟： <1秒
• 用例：语音和实时通信，拍卖和
• 适应性：低
• 支持并发量：小

Meet / Hangouts，Facebook视频聊天和许多其他应用程序的基础并且表现良好。然而，任何经常使用视频聊天技术的用户都能够察觉到这些系统对弱网环境或高丢包有多么敏感，而这些网络环境在家庭用户宽带或蜂窝网络连接条件下非常常见。

由于WebRTC是基于点对点的传输协议，因此一个通话中只允许有限数量的参与者，但是在2018年，我们开始看到一些基于WebRTC构建的通信直播框架可提供面向多人的大规模视频传输系统。在大多数情况下，这是通过将WebRTC中继节点添加到CDN或边缘计算网络中来实现的，从而允许浏览器连接到所需的视频传输对等点。

虽然这种方法是对WebRTC协议的创新使用，但其并非WebRTC的真正设计目标，除非企业对在公共云中运行自己的WebRTC边缘服务器感兴趣，否则不一定采取这种方式。我们很高兴看到主流CDN供应商将在未来一年中推出更多公共WebRTC产品以帮助其他企业实现相似功能——不幸的是，现在仅有一种CDN（Limelight）产品提供类似功能，而过于专注此方向会限制企业的规模并增加企业对供应商的依赖。全方位多样化的CDN使用策略是音视频企业过去几年最重要的发展方向之一——使用像Cedexis这样的工具来执行针对不同情况活动的CDN实时切换，可在确保产品服务正常使用的同时进一步减少延迟并提高终端产品服务的稳定性。

分块传输分段流

• 延迟： 4到1秒之间
• 用例： UGC和互动体验，体育和电子竞技。
• 适应性：中等
• 支持并发量：大

去年年底，我们开始看到一种新的低延迟实时流媒体方案开始受到多个机构的关注并努力实现其标准化。我们已经讨论过分段流媒体如何在今天大规模运行——分块传输解决方案是该解决方案的一个良好的可向后兼容的扩展。

我们知道，一个视频片段由许多视频帧组成，我们将这些被分组的视频帧称为GOP——通常一个视频片段包含多个GOP。要解码一段视频流，我们通常需要一个完整的可用GOP，但这并不意味着必须输入一个完整的GOP至播放器才能实现解码。

通过利用HTTP 1.1规范中鲜为人知的称为“分块传输编码”的功能，播放器可以对一段视频发出标准的HTTP请求，编码器可以在整段视频仍处于编码状态时使用该段的GOP(通常是一个完整的GOP)进行解码操作。使得观众可从视频中任意位置开始观看而非必须等待所有视频帧完成传输与解码之后可观看。

为实现这种功能，除了需要一个支持分块传输与输出的编码器和一个支持此传输模式(大多数CDN已支持)的CDN之外，我们还需要对播放器进行小规模改进以支持这种低延迟流处理方案。然而需要强调的是尽管此方法可以提供令人印象深刻的低延迟数据流表现，但亟需我们解决的挑战仍然存在，即播放器的缓冲区减少。对于遇到卡顿的最终用户，企业可能需要考虑使用更高的延迟策略。

客户端面临的严峻挑战之一是此方法在测量网络性能方面带来的困难。现如今大多数播放器都依赖于视频分片下载性能来衡量可用带宽，但是使用基于分块传输的解决方案，10秒的分片的下载时间为10秒是完全正常的，因为这正是编码器生成块的速度。

真正的好消息是，人们逐渐重视对此方案的研发投入，并努力实现其标准化。目前，有两个小组致力于分块传输分段流的标准化：LHLS（低延迟HLS）社区目前正在HLS-JS项目中定义RFC，我们可以通过Github为此项目提出建议；与此同时CMAF(通用媒体应用程序格式)组的标准化工作也在如期推进，其采用一种独特微妙的方法便是围绕使用符合CMAF的fMP4子片段，而不是TS流段中包含的GOP - 这显然与MPEG-DASH的传输标准非常一致。

这两种方法都已经得到了许多视频流媒体巨头的支持。LHLS目前获得了来自Mux，JWPlayer，Wowza，Akamai，Mist Server和AWS Elemental的支持。除了CMAF社区之外，CMAF方法也得到了很多支持，GPAC，Akamai，Harmonic，Theoplayer，Bitmovin和其他人也做出了贡献。预计在不久的将来们就可以看到这两个群体的融合。特别是，在LHLS manifest中使用CMAF媒体块的能力将引入一种可互换的媒体格式，据客户端的设备，该格式可以提供2种不同的manifest格式。

虽然这些方法还处于标准化过程的早期，但不失为一种有效的探索，其优势在于有效适应现有的多CDN策略并为那些无法支持低延迟策略的播放器提供向后兼容的方法。

专有解决方案

在过去的12个月中，我们可以看到许多新的专有低延迟实时流媒体解决方案开始进入市场，其中大多数使用WebRTC作为传输机制。正如在本文前面已经提到的那样，我们对WebRTC解决方案的供应商封闭与规模限制感到担忧。我们迫切希望看到这些解决方案能够进一步被实践与拓展，以便及时了解这些供应商应对挑战的策略。

以下是我们认为非常有趣的一些专有解决方案：

Limelight视频加速

Limelight与Red5 Pro合作，构建了一个基于WebRTC的解决方案，提供高规模的低延迟实时流媒体体验。我们在IBC（阿姆斯特丹）看到了令人印象深刻的演示：来自美国西海岸的数据流可实现端到端延迟小于500毫秒。

具有超低延迟的Wowza流云

Wowza目前为低延迟实时流提供了几种不同的解决方案，包括称为“WOWZ”的专有技术，该技术可作为其SaaS产品线的一部分使用。当使用Wowza自己的播放器时，WOWZ提供不到3秒的延迟，这使Wowza播放器符合超低延迟的定义，这对规模化部署而言十分重要&规模上是非常令人印象深刻的。正如Wowza的Scott和Jamie在Demuxed 2017中解释的那样，WOWZ协议基于WebSockets。

如果您有支持WebRTC中继的CDN，例如Limelight，您还可以在Wowza的流媒体引擎中利用WebRTC实现更多功能。

Phenix

Phenix是市场上一个相当新的播放器，可提供基于对等网络的实时流媒体解决方案，声称可在全球范围内提供低于500毫秒延迟的流媒体视频传输服务。即使我们还没有看到此解决方案的任何实际应用，但他们声称已经使用AI来解决大量用户突然加入单流时常见的拥塞问题。Phenix似乎在WebRTC的基础上构建了具有专有自定义功能的服务。

Nanocosmos

我们对Nanocosmos的解决方案了解不多，但他们声称拥有可扩展的实时流解决方案并在全球实现亚秒级的网络延迟。我们还没能够深入研究他们的技术，但我们有兴趣观察它的发展并从中获得启发。

Mux的实时流媒体延迟频谱

在过去的12个月里，业内有很多建议术语来描述流媒体领域的不同延迟。我们花了一些时间看看那里有什么，并评估了形势，这是我们的建议。

我们要感谢Will Law在这里启发了我们的定义。

高延迟

• 延迟：超过30秒
• 技术： HLS，DASH，平滑 - 10 秒段
• 用例：延迟无关紧要的直播流Standard Latency

标准延迟

• 延迟： 30到10秒
• 技术：短片段HLS，DASH - 6到2秒片段
• 使用案例：同时播出不希望超越无线广播

低延迟

• 延迟： 10到4秒
• 技术：非常短的段HLS，DASH - 2到1秒段或块式传输HLS / DASH - LHLS / CMAF
• 用例： UGC，现场体验，拍卖，

超低延迟

• 延迟： 4到1秒
• 技术：分块转移HLS / DASH - LHLS / CMAF
• 用例： UGC，现场体验，拍卖，

Sub-Second

• 延迟：不到1秒
• 技术： WebRTC，专有解决方案
• 用例：视频会议，VOIP等

我们还从去年的Demuxed（
https://mux/blog/youtube-viewers-dont-care-about-video-quality/#
3submediasegmentchunkedtransferisbecomingthepreferedwaytoachievelowlatencystreamingatscale）中汇总了我们自己的图表，展示了我们对行业发展的看法。