Glass-to-Glass报告:比较低延迟流媒体提供商

在本文中, 我研究了流式cdn提供的低延迟服务, 删除实际的供应商名称并根据交付方法得出结论. 在讨论测试结果和分析之前，我将首先讨论延迟的基础知识.

延迟的基础

流媒体会议, 演讲者和小组成员经常开玩笑说，自上世纪90年代以来，视频流媒体革命已经如火如荼地进行了几十年，但我们仍然在谈论延迟问题. 流媒体视频的延迟, audio, 数据是流媒体发送视频的时刻和它到达接收器的时间之间的测量间隔. 举个简单的例子, 如果我在下午12:00:01用手机给朋友发了一张照片，我的朋友在12:00:03收到了这张照片, 这是2秒的延迟. 传输的延迟越长，延迟就越大. 当我们使用术语“实时流传输”时,“我们通常指的是500毫秒或更低的延迟，可能在100毫秒至300毫秒之间. 出于本文的目的，我将使用以下定义:

低延迟: 延迟10-12秒
超低延迟: 延迟最多3秒
低于一秒的延迟:延迟小于1秒
实时延迟: 延迟低于500毫秒

对于大量在线观看的媒体来说, 延迟无关紧要, 因为大多数媒体都是按要求存档和服务的, 例如VOD内容. 此外，一个查看器的开始时间与另一个查看器的开始时间是异步的. 我可以在YouTube上开始一个视频, 我的开始时间不需要指示其他观众的开始时间. 从一个供应商到另一个供应商可能存在缓冲延迟, 但对记录内容的看法是，它发生在过去, 所以你通常不需要觉得自己是在“实时”观看它.”

然而，对于实时内容，即时性的感知确实很重要. 这种即时性的紧迫性在很大程度上取决于实时事件或会话期间发生的任何交互或事务. 如果我决定什么时候按下一个按钮买卖股票, 我想要一个小于1秒延迟的实时数据馈送吗, 或者我想看延迟的买入/卖出数据? 类似的, 如果你正在观看一场体育赛事，并且能够对该赛事下注, 您将需要接近实时的延迟以及与其他查看器的紧密同步. 在现场活动期间的拍卖和任何限时销售将具有尽可能低延迟的相同期望. 使用视频的安全和监视操作, audio, 数据还将具有低延迟的功能性和非功能性需求.

影响延迟的因素

在任何传输过程中都有几个变量影响实时时刻到接收端的延迟. 具有实时视频和音频流, “玻璃到玻璃的延迟”这个短语经常被用来描述光线从穿过相机镜头到出现在观看者屏幕上的时间延迟. 直播流延迟的主要影响因素包括以下几点:

现场传输时间: 摄像机和视频交换机处理视频信号所需的时间通常很短，并以帧数来衡量, 参考制作中使用的帧率. 例如, sdi到hdmi转换器通常会在视频信号路径中增加一帧延迟.
视频压缩: 无论您使用的是基于软件还是硬件的编码器, 为了有效地将未压缩的视频比特率压缩到流媒体所需的较低比特率，视频信号需要一个最小的缓冲区. 根据您的特定编码器，此延迟可能很大，范围从10毫秒到几秒钟. 关键帧间隔(也称为图像组(GoP))也会增加延迟.
到源的流协议: 用于将实时流出站从编码器推送到流CDN摄取的协议可能会增加延迟. 目前使用的典型协议包括RTMP、SRT、RTSP和WHIP (webtc - http摄取协议). 根据实现的不同，它们会在不同程度上影响端到端延迟.
往返进食时间(RTT): 不管流协议是什么, 将音频/视频/数据包发送到提供商的存在点(POP)或摄取服务器并返回确认所花费的时间会极大地影响延迟. 如果一个现场活动在西雅图进行，而POP在欧洲的某个地方, 流数据包必须经过更多的跳数才能到达源服务器, 因此，将更多的时间添加到延迟方程中.
自适应代码转换: 大多数从事低延迟业务的cdn必须处理用于为直播流创建多种质量(或比特率)的编码阶梯，以确保他们的播放器技术在广泛的网络条件下可预测地工作. 正如本地编码器会影响延迟一样，服务器端编码技术也会影响延迟.
边缘缓存: 每个CDN都有特定的方法来处理地理区域内和跨地理区域的并发负载. 就像RTT一样, 流数据包从边缘服务器到查看者设备必须经过的跳数将影响延迟.
流协议的观众: 尽管像RTMP和RTSP这样的传统传输仍然存在于今天的广播和流工作流程中, 目前大多数低延迟的流部署都使用WebRTC, WSS (WebSocket Secure), 或高度优化的HTTP交付. WebRTC是唯一一个可以选择使用UDP数据包传输的流行协议, 哪一种比tcp传输的数据包更容易丢帧.
球员实现: 就像视频编码器在压缩开始之前有一个内部缓冲区一样, 设备上的视频播放也需要在解码帧开始之前建立一个本地缓存或缓冲区. 大多数CDN供应商都有定制的播放器sdk来优化他们向观众提供的低延迟内容. 玩家也可以极大地影响整体延迟的大小.

跨屏幕同步

仅仅因为直播流具有端到端的低延迟并不一定意味着所有观众都在同一时间看到相同的时刻. 由于网络条件不同，多个并发会话之间也会存在差异, 处理速度, 以及观看者设备上的电源可用性/功耗.

对于许多应用程序，特别是对于仅在线的事件，其中所有查看者需要在会话期间使用连接的设备进行事务处理，跨多个屏幕的同步将比总体延迟重要得多. 我无法强调同步对于您的特定业务需求有多么重要. 延迟通常与有效的同步有关, 并且，您可能希望有意地在实时会话中添加更多延迟，以确保观看者彼此之间更加同步. 更大的缓冲时间, 例如, 能否允许视频播放器技术在会话期间始终保持在同一时间点.

测试:方法

现在我们已经了解了延迟和同步的基本知识, 让我们直接进入我为本文进行的实际测试. 时间和预算必然限制了测试的范围, 限制了我可以测试的供应商的数量. 本文的目的不是挑出任何特定的供应商. 我从使用不同传输协议的选定供应商的测试中收集数据，以确定数据支持的趋势. 我选择了使用以下运输方式的供应商. “x”因素是我用该协议测试了多少供应商.

WebRTC x2: 使用HTML5和本地应用程序支持的标准的实时流的事实标准, 当Flash播放器技术和RTMP播放从设备和操作系统中消失时，WebRTC迅速进入了人们的视野. WebRTC可以利用UDP和TCP流，并且在设计上是编解码无关的. 目前在web浏览器和本地应用程序中广泛使用的编解码器包括H.264用于视频，Opus用于音频. Not all WebRTC vendors provide TURN (Traversal Using Relays around NAT) support by default; TURN allows viewers who are connected behind complex firewalls 和/or VPNs to receive packets that would otherwise fail.
LL-HLS x1: 低延迟HTTP实时流(LL-HLS)已经开发了好几年了, 但大多数HLS实现的延迟都在30秒左右, 因为更大的块段减少了播放器和服务器之间的HTTP调用数量. LL-HLS的新版本大大减少了段大小，允许更小的延迟时间. LL-HLS的实现可能差别很大.
HESP x1: 高效流协议(High Efficiency Stream Protocol, HESP)是一种较新的HTTP流协议，旨在为典型的HTTP部署(如LL-HLS)提供更好的替代方案. HTTP基础设施通常比其他传输更便宜，更容易扩展.
websocket x2: 一些供应商使用WebSockets技术销售低延迟服务. 这种传输比WebRTC存在的时间要长得多，可以用于广泛的低延迟内容, 从实时文字聊天到近乎实时的视频和音频传输. 而像WebRTC和HLS这样的其他传输通常可以利用非供应商特定的视频播放技术, 提供WebSockets流媒体的供应商要求他们的嵌入式播放器能够跨平台工作.

所有选择用于测试的供应商都有一个可用的RTMP摄取POP, 因为我希望编码器的出站传输在测试目标之间保持一致. 所有回放使用嵌入式播放器技术可从每个供应商. 在测试期间对带宽进行了限制，以查看在各种网络条件下播放效果如何.

测试:环境

为了测量端到端(或“玻璃到玻璃”)延迟, 我从自己的真实世界的直播制作设备中组装了许多组件, 以及其他软件来控制带宽节流. 以下是所使用的组件和设置的顺序:

带有SDI输出的vMix切换器: 以60帧/秒的速度录制的测试剪辑在Windows PC上的vMix中循环播放，并通过Blackmagic Design SDI PCI卡外部输出到外部供电的Atomos Shogun Inferno. 从vMix的程序输出包括在显示器的右上角烧坏挂钟(见图1).
video EdgeCaster 4K编码器: 从幕府地狱的HDMI输出被馈送到H.264/AAC编码器使用“最低延迟”预设在编码器和使用1秒的关键帧间隔. 所有流都使用RTMP或RTMP传输到提供商的摄取.
连接设备: 所有的设备屏幕都被安排在一张桌子上，在播放中显示直播流(见图1). 所有会话使用的测试设备包括:

2016年三星Galaxy S7安卓手机(5 GHz Wi-Fi)
2023三星Galaxy A54安卓手机(5 GHz Wi-Fi)
2021苹果iPhone 13 (5 GHz Wi-Fi)
2011年Windows i7与NVIDIA GeForce RTX 3060 GPU桌面(有线以太网)
2017年Apple i7 MacBook Pro(有线以太网)
2021 HP AMD Athlon Gold笔记本电脑(有线以太网)

网络控制: 通过vMix交换器PC上的NetBalancer软件控制网络条件，模拟4G和5G网络条件. 在连接到华硕Wi-Fi路由器的第二块网卡上启用了Windows Internet Sharing, NetBalancer也对这个网络的带宽进行了限制. NordVPN用于将惠普笔记本电脑连接到位于德国的专用VPN服务器.
相机捕捉: 使用索尼NEX-7相机，以高帧率(1/500秒)捕捉测试过程中的时刻，以获得清晰的挂钟信息. 手动查看挂钟时间戳，并将其输入电子表格，以测量设备和源之间的差异.

图1. 与每个供应商测试的连接设备阵列

测试:程序

在与每个供应商进行初始测试之后, 每个实时流会话都经过以下耗时的测试过程，以捕获延迟和同步数据. 每一轮需要60-90分钟才能完成, 总共18轮(每个供应商三个连接，六个供应商):

输出vMix馈送到外接的SDI监视器: vMix会话只负责播放一个循环4K 60帧/秒的视频到一个1080p 60帧/秒的节目馈送显示在幕府地狱. 添加了一个vMix标准挂钟，显示小数秒.
配置RTMP编码器: Videon EdgeCaster 4K使用相同的编码配置文件向供应商推送RTMP流. 大多数供应商提供的POP摄取地点在地理上离我在温哥华附近的位置很近, 加拿大.
配置带宽限制软件: 为此采样测试了三种网络条件:未过滤(NetBalancer禁用), 商务级电缆调制解调器的全吞吐量), 4G, 和5克.
进行带宽测试: 每台设备都在Netflix的FAST上进行了测试.Com服务测量并确认存在已节流或未节流的速度.
播放直播流: 每个厂商的播放器都嵌入在一个专门的网页上，由我自己的videorx提供服务.. Com网站.
捕捉实时流挂钟图像: 在每种网络条件下，取5个样本，每次间隔约5分钟. 为防止时间戳的易读性模糊，每次采样拍摄两张照片.
审查捕获数据并将数据输入电子表格; 一轮拍摄结束后，我查看了每张照片，并将时间戳输入电子表格.

测试:结果

测试结束后，我建立了电子表格来计算以下值(图2 显示从电子表格中截取的屏幕截图):

每个设备之间的时间戳差异: 电子表格中的12列计算了每种可能的设备组合之间的时差:iOS到Android Legacy, iOS到Android, iOS到VPN PC, 诸如此类. 这些值将帮助我们了解在每个会话期间同步维护得如何.
每个设备的源时间戳差异: 六列计算源壁钟(vMix生成输出到Inferno显示)和每个设备之间的延迟. 这些值将显示哪个传输和供应商具有最佳的总体延迟.
每个网络条件下的平均延迟: 从每个连接速度测试所取的5个样本中计算平均值.
所有网络条件下的平均延迟: 从每个供应商/运输的所有15个样本中计算平均值.
设备同步的均值标准差: 所有设备同步差异的标准偏差是根据连接速度和总体计算的. 较低的标准偏差意味着同步结果之间的时间差较小, 和, 像这样, 更好的同步.

图2. 电子表格数据收集. 单击图像以查看其全尺寸.

任何熟悉统计和分析的人都知道，更多的抽样意味着更多的数据和更准确的结果，从而得出结论. 最初, 我开始时每个连接速度只有3个采样, 后来我把采样增加到五个快照，以隔离异常值，并有更多的数据用于计算. 表1 显示供应商之间的平均值和标准偏差的顶点. 所有值都以秒为单位显示. 绿色值表示类别中最佳, 黄色表示该类别第二好, 红色表示最差.

运输	正常网络STD	5 g NetworkSTD	4 g NetworkSTD	综合网络STD	正常网络时延	5G 网络延迟	4 g Network延迟	结合网络延迟
WSS	0.10	0.47	0.64	0.50	1.17	1.43	1.78	1.46
WSS	0.23	0.82	2.75	1.79	0.97	1.63	1.97	1.52
WebRTC	0.23	0.66	0.92	0.65	1.07	1.30	2.20	1.30
WebRTC-TURN	0.07	0.28	0.72	0.47	0.58	0.69	2.34	1.25
HESP	0.33	1.34	0.57	0.96	1.12	1.17	1.94	1.80
LL-HLS	2.49	3.10	12.57	8.12	18.91	19.15	21.19	19.75

表1. 供应商之间的平均值和标准差

根据我收集的数据，我确定了以下趋势:

较慢的网络速度导致设备之间的漂移增加和延迟值增大.
一个内置TURN支持的WebRTC供应商总体上保持了最好的同步和延迟.
一个WebSocket供应商在各种网络条件下的设备之间具有最一致的同步，在最紧张的(4G)网络条件下具有最低/最佳延迟. 这家厂商在4G模拟下的播放效果也是最流畅的, 这里的摊位比其他摊贩要少得多.
最新的协议, HESP, 与测试的其他运输相比，它的表现始终优于LL-HLS，总体排名也很好.
所选供应商的LL-HLS在所有类别中表现最差.
较旧的设备和通过VPN连接连接的设备可能具有较高的延迟值.

结论

虽然我怀疑WebRTC供应商总体上会做得更好, 看到WebSockets和HESP技术表现得如此出色，我感到非常惊喜. 从我为客户提供解决方案的经验来看, 与其他低延迟技术相比，WebRTC供应商的成本通常更高. 我预计WebRTC在有压力的网络条件下会表现得更好, 但是HESP和WebSockets提供商在同步方面做得更好, 在收集的所有样本中，大多数类别在1秒以下. 如果你想探索webbrtc流媒体, 确保供应商提供TURN支持，以便访问更复杂防火墙后面的查看者. 定价可能会根据您需要从任何供应商处获得的选项而有所不同.

我收集到的数据还远没有达到100%的结论, 但这是迄今为止我收集到的比较低延迟技术的最多数据.

正如我在过去的文章中所建议的那样, 一定要彻底测试你想用视频流管道实现的任何新解决方案. 不要认为供应商网站上展示的演示考虑了所有会影响您特定实现的变量, 不要仅仅因为某个供应商使用了某种特定的技术，就认为它会在同类产品中胜过所有其他厂商. 在使用任何供应商提供的流传输之前，花点时间通过执行自己的测试来做出明智的决定.

您可以访问完整电子表格数据的链接列表 videorx.com/low-latency/tests