2019年低延迟直播技术展望

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

文 / Phil Cluff

译 / 元宝

审校 / 傅德良

原文

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

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

延迟在什么时候很重要？

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

语音和实时通信

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

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

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

例子：

体育和电子竞技

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

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

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

例子：

交互式体验和交互式UGC流

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

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

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

Streamer sodapoppin在视频赌场下注很大

例子：

低延迟权衡

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

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

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

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

减少延迟的方法

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

采用短视频分片长度

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

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

实时协议

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

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

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

分块传输分段流