Vindral:可靠 & 可扩展的超低延迟视频播放

At a presentation I gave at Streaming Media East this past May, 我回顾了目前市场上可用于实时流需求的低延迟选项—主要是从内容提供商和提供这些堆栈的供应商可用的各种技术堆栈的角度. 从最低延迟到最高延迟, 这些选项包括WebRTC, WebSocket, CMAF的变化, HLS(苹果的HTTP Live Streaming方法)和DASH.

For any stakeholder with live streaming business requirements, the myriad of options can be overwhelming and easily misunderstood. 选择错误的解决方案或方法可能会给客户带来不一致的结果, as well as expensive reworking of the tech stacks down the road. Moreover, many of these tech stacks undergo massive changes from one release to the next, 使用来自浏览器厂商的混合实现.

Enter RealSprint’s newest low latency streaming CDN solution: Vindral. Vindral使用WebSockets技术作为其一秒内实时内容交付的基础. In this article, 我解释了为什么WebSockets技术可能是直播的最佳选择，以及为什么Vindral在低延迟市场中被定位为首屈一指的CDN.

Note: 为了讨论的目的, 我将关注一对多业务需求, where an origin stream needs to be shared with many subscribers in real-time, 区域性或全球性.

流媒体技术入门

让我们比较一下当前的低延迟堆栈，以便更好地了解每个堆栈所涉及的技术需求. 了解部署中的差异将帮助您确定应该使用哪种流传输来为您的客户提供优质的观看体验.

HTTP流:CMAF, HLS和DASH的变化

流传输的圣杯之一是能够使用现有的HTTP扩展架构来提供高容量和可靠的服务. In short, if you can scale general web content with CDNs for HTTP traffic, you should be able to use the same scaling mechanisms for streaming video. For latency in streaming playback, several factors can come into play. 通过TCP传输的HTTP数据包的往返时间(RTT)会给流增加一些延迟. HTTP caching is also a primary component of CDN architectures, 根据定义，缓存需要写入和存储内容，这也增加了延迟. More importantly, CMAF, HLS, 和DASH都是清单驱动格式，其性能在很大程度上取决于在web应用程序或设备应用程序中运行的视频播放器代码.  视频播放器必须不断地获取流的“内容表”——通常深度不止一层——然后才能开始加载和播放参考流的片段. Segment duration is also a key factor in determining latency with these formats. 由于此类流是通过HTTP或HTTPS协议在标准TCP端口上提供的, 网络防火墙通常不会拒绝这种通信. 因此，您可以放心，内容的播放问题将很少受到关注.

在过去的几年里, Low Latency HLS, or LL-HLS, has been in development by Apple and other major vendors including Vindral. 与典型的HTTP流格式相比，LL-HLS的核心改进是进一步减小了数据块或数据段的大小——视频播放器可以更可预测地获取较大数据块或数据段的最新部分，而无需等待其他部分预加载. While the specification is an improvement over traditional HLS deployment, 跳过段或帧以保持与实时流的同步并不容易. 在我用LL-HLS做的早期测试中, 随着播放时间的增加，直播流经常会偏离实时同步. 大多数现成的网络视频播放器需要一个特定的LL-HLS实现才能工作. Vindral正在积极开发他们自己的LL-HLS部署，以增强他们现有的WebSockets交付系统. 拥有多种可用的传输技术可确保在目标受众使用的各种网络环境和操作系统中成功地播放流.  

WebRTC

随着Adobe的Flash技术及其RTMP流媒体播放从网络和本地应用领域消失, a new real-time protocol came about: WebRTC (Real Time Communication). 这个新协议承诺使用HTML5标准为web应用程序添加实时音频和视频流. WebRTC可以在各种交付场景中工作, including P2P (Peer to Peer) where clients send packets directly to each other, SFU (Selective Forwarding Unit) where servers broker packets between clients, MCU(多点控制单元)，其中服务器合并来自客户端的多个音频和/或视频上游数据包，为每个连接的客户端创建单个下游. After a WebRTC client connects to a server and negotiates its path to content, the audio and video are delivered over TCP and/or UDP ports, ideally the latter—particularly when it comes to sub one second latency. WebRTC packets received by the client have minimal buffering, 并使用UDP传输, packets can be dropped much more easily to keep up with real-time playback.

As one of WebRTC’s original intentions was to enable real-time audio, video, and data between multiple clients sharing data with each other (e.g. 音频/视频会议), the emphasis was on keeping interactions as real-time as possible, 延迟可以忽略不计. As a result, 视频流的质量可能会波动，以保持实时播放——播放质量的控制可能不在播放器技术的掌握之中，而是潜在的本地浏览器api. Video playback might not be able to maintain high bitrate, high quality, and high frame rate over WebRTC and achieve ultra low latency at the same time.

WebSockets

WebSockets如何适应流解决方案? In short, WebSockets几乎可以提供任何类型的二进制“数据”。, 比如音频或视频包, 通过客户端(如浏览器中运行的web应用程序)和服务器之间的实时双向套接字. The client can receive data as well as send information back to the server. Many types of applications can be built on top of WebSockets technology, from real-time chats to low-latency streaming video and audio.

More importantly, WebSockets have been around for a long time! 该规范于2008年首次引入, and by 2011, 每个主要的浏览器供应商都支持不安全的WebSocket (ws://)和安全的WebSocket (wss://)协议. 后一种协议使用标准TLS加密，就像web浏览器中的HTTPS连接一样. 在安全WebSocket连接之上构建服务的供应商可以对基于浏览器多年实现的可靠技术充满信心. 其他用于传输低延迟内容的技术就不能这么说了.

WebSockets上音频和视频内容的播放和多比特率控制并不是由web浏览器中的本地媒体api提供的. 大多数WebSockets视频播放是特定于依赖于HTML5媒体源扩展(MSE)的定制播放器代码库的。. Every WebSocket streaming vendor has a proprietary system for delivering content.

WebSocket技术的商业案例

For low-latency streaming that isn’t based on HTTP or HTTPS like HLS or DASH, 两个最大的竞争者是WebRTC和WebSockets. 如前一节所讨论的, webbrtc和WebSockets在客户端和服务器之间建立了双向通信, enabling much more finesse and control over sent and received data, 比如丢帧, 往返时间(RTT), and much more.

那么如何在webbrtc和WebSockets之间进行选择呢? Clearly, they are the two lowest latency options, but which is “better”? While each use case and business requirement can be unique, 以下是选择WebSockets流解决方案而不是webbrtc流解决方案的五个原因:

• Scalability: Typically, WebSockets server technology is easier to scale across the cloud. 从网络和跨区域的角度来看，使更多的WebSocket边缘到WebSocket起源要比WebRTC简单得多.
• Firewalls: WebSockets使用与其他web流量相同的端口:通常TCP端口80用于不安全的流量, TCP端口443用于安全流量. Most firewalls allowing web traffic will also allow WebSocket traffic, making it much easier to get your content to ever-increasing locked down networks. WebRTC, 另一方面, can have difficulty getting across the Internet and into a LAN environment, 特别是当流量通过带有非对称NAT(自然地址转换)的移动运营商网络时。. WebRTC需要使用另一层传输, TURN, 或在NAT周围使用中继进行遍历, to do exactly that: get around the problem of NAT environments.
• Cost: 使用WebSockets的服务在云中运行和维护的成本通常比其他竞争的实时技术(如WebRTC)要低. 与webbrtc供应商相比，WebSocket流媒体供应商的成本通常更低.
• 编解码器的一致性: WebSockets可以使用特定的视频和音频编解码器，这些编解码器在web浏览器中运行的客户端应用程序之间是一致的, unlike WebRTC which may fallback on specific codecs favored by the browser vendor.
• 开发者学习曲线: SDKs for one-to-many WebSocket services are much easier to implement and control, 因为在WebRTC上需要考虑的变量更少. 这种易用性意味着更快的开发时间、更快的测试和更快的部署. 

Vindral’s core streaming solution is based on WebSockets technology, 即将对LL-HLS提供支持. 在下一节中，您将了解为什么Vindral的实现适合一对多的实时流部署.

为什么Vindral很特别?

在确信WebSockets技术更有可能满足您对超低延迟解决方案的业务需求之后, your next step is to determine your path to its implementation. 经典的“构建还是购买”困境同样适用于超低延迟流，也适用于产品和软件开发过程的其余部分. 

全面介绍低延迟WebSockets流云架构和解决方案的组件超出了本文的讨论范围, 但至少你需要开发以下内容: 

• 摄取架构: How are you going to ingest from your publishing points such as H.264流媒体设备或应用? 你的摄取需要存在于哪些区域?
• Edge-origin架构: 如何从给定的原始源实时扩展必要的边缘服务器?
• Video playback: 你将使用什么指标来确定帧数下降, 视频质量切换, 以及在观众之间同步播放? How will those metrics be implemented in a web application or native application? Are your software developers savvy with media APIs and event handling? 您将如何管理音频和视频缓冲?
• 编码规范: 对于摄取和播放，您将支持哪种编解码器? 如何控制所选编解码器的属性以提供优越的观看体验?
• 代码转换实现: 大多数流媒体解决方案需要考虑自适应比特率播放，以便内容在各种网络条件下流畅且不间断地播放. 如何创建和管理转码百家乐软件? Do you build your own custom encoder solution or rely on another service? 

这些项目只是考虑您自己的自定义构建流解决方案的起点. 当你得出结论，寻求一个基于WebSockets技术的一体化流媒体CDN比自己构建更好, you’re now comparing vendors offering an ultra latency solution. 

Figure 1: 实时流云架构的入口/出口 

In my own independent testing of Vindral against competing vendors, 我发现Vindral在播放弹性和播放响应性方面表现出卓越的性能.

回放弹性

我对Vindral体验到的第一个“哇”因素是它在低带宽或缺乏带宽条件下的表现. 使用FFmpeg作为RTMP编码器生成1080p 30fps 8Mbps流到Vindral和其他竞争对手, 我发现使用Vindral的WebSocket平台的播放器逻辑在连接速度低于源比特率的情况下始终提供更流畅的播放体验. 使用NetBalancer作为带宽节流工具，模拟4G和5G连接条件, Vindral playback and performance were consistent across devices. 

而我只测试了1080p播放, 在进行具体部署之前，应该始终对4K或8K等更高分辨率进行测试和验证, as these resolutions will likely fit into your long term roadmap. 在支持4K和HDR播放的基础上, 在今年的IBC展示会上, Vindral的团队演示了8K流的技术预览，它和其他内容一样出色. 

使用受限的网络条件，例如可能存在于VPN或隐私保护网络软件的网络条件, Vindral again performed consistently across devices and browsers. 一些被测试的WebRTC实现无法建立连接或测试流的回放, 可能是由于缺乏在更严格的网络规则下工作的TURN回退.

回放反应

Vindral的嵌入式播放器在其他性能类别中也表现良好，包括: 

• 第一帧时间: Player initialization and start times were exceptionally fast, 通常在300到600毫秒之间, 低至200毫秒. 客户可以在Vindral门户的Analytics部分查看此统计信息和其他信息(参见图2)。.
• 缓冲和同步控制: 播放的最小和最大缓冲时间可以通过传递给嵌入式播放器的变量轻松调整, 1秒的缓冲时间在全帧速率下流畅播放，在测试设备之间的变化在100ms以下.
• 自适应比特率: Vindral的摄取服务将源流转换为Vindral门户帐户的Transcoding Profiles部分中指定的形式. 播放过程中的手动切换是无缝的, 在质量切换过程中，模拟的带宽限制不会中断播放.

Figure 2: Vindral会话的分析概述

Cost

作为我对温德尔尔的回顾的一部分, I presented past client engagements and deployment strategies to the Vindral team. 通常, 对于同样的目标受众和流媒体质量，Vindral的成本比其他供应商目前的成本低50%. Vindral还提供了灵活的业务模型和针对您的部署需求的定制定价. 如果您使用AV1等下一代编解码器，您也将受益于较低的流量.            

Next Steps

那你下一步打算怎么办? When you’re ready to switch from your current streaming deployment to Vindral, 你需要考虑什么? 我建议我的客户尽可能客观地评估一项新技术或服务: 

• 实施快速概念验证(PoC): Build a test harness to compare player implementations for your streaming content, 这样你就可以比较实时同步和源.
• 确定您的最大源流计数: How many incoming sessions do you need to support independently and concurrently? Identify which geographic regions will be needed to support your source streams. 供应商成本可能因摄取费用而有很大差异.
• 监控性能: 建立程序来衡量对你的观看体验很重要的指标, 并根据需要跟踪指标. 

In summary, 当前的低延迟直播生态系统涉及几种不同的技术来实现相同的结果:在各种设备上的播放一致性和在恶劣网络条件下的弹性. 在实现新的流解决方案之前，请确保花时间正确评估当前和未来的业务需求. 

vindral.com

这篇文章是赞助内容