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

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

延迟的基础

流媒体会议, speakers 和 panelists often joke that we’re still talking about latency decades after the start of the video streaming revolution that’s been in full swing since the 1990s. 流媒体视频的延迟, audio, 数据是流媒体发送视频的时刻和它到达接收器的时间之间的测量间隔. 举个简单的例子, 如果我在下午12:00:01用手机给朋友发了一张照片，我的朋友在12:00:03收到了这张照片, 这是2秒的延迟. 传输的延迟越长，延迟就越大. 当我们使用术语“实时流传输”时,“我们通常指的是500毫秒或更低的延迟，可能在100毫秒至300毫秒之间. 出于本文的目的，我将使用以下定义:

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

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

然而，对于实时内容，即时性的感知确实很重要. The urgency of that immediacy largely depends on any interactions or transactions taking place during the live event or session. 如果我决定什么时候按下一个按钮买卖股票, 我想要一个小于1秒延迟的实时数据馈送吗, 或者我想看延迟的买入/卖出数据? 类似的, 如果你正在观看一场体育赛事，并且能够对该赛事下注, 您将需要接近实时的延迟以及与其他查看器的紧密同步. Auctions 和 any time-limited sales during a live event will have the same expectations of the lowest latency possible. 使用视频的安全和监视操作, audio, 数据还将具有低延迟的功能性和非功能性需求.

影响延迟的因素

在任何传输过程中都有几个变量影响实时时刻到接收端的延迟. 具有实时视频和音频流, the phrase “glass-to-glass latency” is often used to describe the time delay between the moment light passes through a camera lens 和 the moment it appears on a viewer’s screen. 直播流延迟的主要影响因素包括以下几点:

• 现场传输时间: The time it takes for the video signal to be processed by cameras 和 video switchers is usually very low 和 measured by frame count, 参考制作中使用的帧率. 例如, sdi到hdmi转换器通常会在视频信号路径中增加一帧延迟.
• 视频压缩: 无论您使用的是基于软件还是硬件的编码器, the video signal needs a minimal buffer in order to efficiently compress the uncompressed video bitrate to a lower bitrate needed for streaming. 根据您的特定编码器，此延迟可能很大，范围从10毫秒到几秒钟. 关键帧间隔(也称为图像组(GoP))也会增加延迟.
• 到源的流协议: 用于将实时流出站从编码器推送到流CDN摄取的协议可能会增加延迟. 目前使用的典型协议包括RTMP、SRT、RTSP和WHIP (webtc - http摄取协议). 根据实现的不同，它们会在不同程度上影响端到端延迟.
• 往返进食时间(RTT): 不管流协议是什么, the time it takes for a packet of audio/video/data to be sent to a provider’s point of presence (POP) or ingest server 和 return confirmation can greatly influence latency. 如果一个现场活动在西雅图进行，而POP在欧洲的某个地方, 流数据包必须经过更多的跳数才能到达源服务器, 因此，将更多的时间添加到延迟方程中.
• 自适应代码转换: Most CDNs in the business of low latency necessarily want to h和le the encoding ladder used to create multiple qualities (or bitrates) for live streaming to ensure that their player technology works predictably across a wide range of 网work conditions. 正如本地编码器会影响延迟一样，服务器端编码技术也会影响延迟.
• 边缘缓存: 每个CDN都有特定的方法来处理地理区域内和跨地理区域的并发负载. 就像RTT一样, the number of hops that stream packets have to cross to get from an edge server to the viewer’s device will affect latency.
• 流协议的观众: 尽管像RTMP和RTSP这样的传统传输仍然存在于今天的广播和流工作流程中, 目前大多数低延迟的流部署都使用WebRTC, WSS (WebSocket Secure), 或高度优化的HTTP交付. WebRTC是唯一一个可以选择使用UDP数据包传输的流行协议, 哪一种比tcp传输的数据包更容易丢帧.
• 球员实现: 就像视频编码器在压缩开始之前有一个内部缓冲区一样, 设备上的视频播放也需要在解码帧开始之前建立一个本地缓存或缓冲区. 大多数CDN供应商都有定制的播放器sdk来优化他们向观众提供的低延迟内容. 玩家也可以极大地影响整体延迟的大小.

跨屏幕同步

Just because a live stream has end-to-end low latency doesn’t necessarily mean that all viewers are seeing the same moment at the same time. 由于网络条件不同，多个并发会话之间也会存在差异, 处理速度, 以及观看者设备上的电源可用性/功耗.

For many applications—和 particularly for online-only events in which all viewers need to be using a connected device to make transactions during the session—synchronization across multiple screens will be much more important than the overall latency. 我无法强调同步对于您的特定业务需求有多么重要. 延迟通常与有效的同步有关, 和 you may want to intentionally add more latency to a live session to ensure that viewers are more in sync with each other. 更大的缓冲时间, 例如, 能否允许视频播放器技术在会话期间始终保持在同一时间点.

测试:方法

现在我们已经了解了延迟和同步的基本知识, 让我们直接进入我为本文进行的实际测试. 时间和预算必然限制了测试的范围, 限制了我可以测试的供应商的数量. 本文的目的不是挑出任何特定的供应商. I collected data from my own tests with selected vendors using different transport protocols to determine trends that the data supported. 我选择了使用以下运输方式的供应商. “x”因素是我用该协议测试了多少供应商.

• WebRTC x2: 使用HTML5和本地应用程序支持的标准的实时流的事实标准, WebRTC quickly came onto the scene when Flash Player technology 和 RTMP playback evaporated from devices 和 operating systems. 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) is a newer HTTP streaming protocol that aims to provide a better alternative to typical HTTP deployments such as LL-HLS. HTTP基础设施通常比其他传输更便宜，更容易扩展.
• websocket x2: 一些供应商使用WebSockets技术销售低延迟服务. 这种传输比WebRTC存在的时间要长得多，可以用于广泛的低延迟内容, 从实时文字聊天到近乎实时的视频和音频传输. 而像WebRTC和HLS这样的其他传输通常可以利用非供应商特定的视频播放技术, 提供WebSockets流媒体的供应商要求他们的嵌入式播放器能够跨平台工作. 

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

测试:环境

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

1. 带有SDI输出的vMix切换器: A test clip recorded at 60 fps was played on a loop within vMix on a Windows PC 和 externally output via a Blackmagic Design SDI PCI card to an externally powered Atomos Shogun Inferno. 从vMix的程序输出包括在显示器的右上角烧坏挂钟(见 图1).
2. video EdgeCaster 4K编码器: 从幕府地狱的HDMI输出被馈送到H.264/AAC编码器使用“最低延迟”预设在编码器和使用1秒的关键帧间隔. 所有流都使用RTMP或RTMP传输到提供商的摄取.
3. 连接设备: 所有的设备屏幕都被安排在一张桌子上，在播放中显示直播流(见 图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笔记本电脑(有线以太网)

1. 网络控制: NetBalancer software on the vMix switcher PC controlled the 网work conditions to emulate 4G 和5克 网work conditions. 在连接到华硕Wi-Fi路由器的第二块网卡上启用了Windows Inter网 Sharing, NetBalancer也对这个网络的带宽进行了限制. NordVPN用于将惠普笔记本电脑连接到位于德国的专用VPN服务器.
2. 相机捕捉: Moments in time during test procedures were captured at a high frame rate (1/500 second) for clarity of wall clock info using a Sony NEX-7 camera. Wall clock timestamps were manually reviewed 和 typed into a spreadsheet to measure the variations between devices 和 the source.

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

测试:程序

在与每个供应商进行初始测试之后, each live-stream session went through the following time-intensive testing procedure to capture latency 和 synchronization data. 每一轮需要60-90分钟才能完成, 总共18轮(每个供应商三个连接，六个供应商):

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

测试:结果

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

• 每个设备之间的时间戳差异: Twelve columns in the spreadsheet calculated the time difference between each possible combination of devices: iOS到Android Legacy, iOS到Android, iOS到VPN PC, 诸如此类. 这些值将帮助我们了解在每个会话期间同步维护得如何.
• 每个设备的源时间戳差异: Six columns calculated the latency between the source wall clock (vMix generated output to Inferno display) 和 each device. 这些值将显示哪个传输和供应商具有最佳的总体延迟.
• 每个网络条件下的平均延迟: 从每个连接速度测试所取的5个样本中计算平均值.
• 所有网络条件下的平均延迟: 从每个供应商/运输的所有15个样本中计算平均值.
• 设备同步的均值标准差: 所有设备同步差异的标准偏差是根据连接速度和总体计算的. 较低的标准偏差意味着同步结果之间的时间差较小, 和, 像这样, 更好的同步.

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

Anyone familiar with statistics 和 analysis knows that more sampling means more data 和 more accurate results from which to draw conclusions. 最初, 我开始时每个连接速度只有3个采样, 后来我把采样增加到五个快照，以隔离异常值，并有更多的数据用于计算. 表1 显示供应商之间的平均值和标准偏差的顶点. 所有值都以秒为单位显示. 绿色值表示类别中最佳, 黄色表示该类别第二好, 红色表示最差.

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

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

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

结论

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

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

正如我在过去的文章中所建议的那样, 一定要彻底测试你想用视频流管道实现的任何新解决方案. Don’t assume that demos shown on vendor’s websites take into account all of the variables that will affect your specific implementation, 和 don’t assume that just because a vendor is using a particular technology that it’s going to outperform all others in its class. Take the time to make an informed decision by conducting your own tests before committing to a streaming transport provided by any vendor.

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