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. Picking the wrong solution or approach would likely lead to inconsistent results for the customer, 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 uses WebSockets technology as the foundation for its sub one second delivery of live content. In this article, 我解释了为什么WebSockets技术可能是直播的最佳选择，以及为什么Vindral在低延迟市场中被定位为首屈一指的CDN.

Note: 为了讨论的目的, I will be focusing on one-to-many business requirements, 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. Round trip time (RTT) for HTTP packets over TCP is going to add some latency to the stream. HTTP caching is also a primary component of CDN architectures, and caching by definition requires content to be written and stored–also adding to latency. 更重要的是, CMAF, HLS, 和DASH都是清单驱动格式，其性能在很大程度上取决于在web应用程序或设备应用程序中运行的视频播放器代码.  视频播放器必须不断地获取流的“内容表”——通常深度不止一层——然后才能开始加载和播放参考流的片段. Segment duration is also a key factor in determining latency with these formats. As streams in this category are served over HTTP or HTTPS protocols on standard TCP ports, 网络防火墙通常不会拒绝这种通信. Therefore, you have some reassurance that playback issues of content will be of little concern.

在过去的几年里, 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, it’s not as easy to skip segments or frames to maintain synchronization with a real-time stream. 在我用LL-HLS做的早期测试中, live streams would often drift out of sync from real-time as playback time increased. Most off-the-shelf web video players need a specific LL-HLS implementation in order to work. Vindral is actively working on their own LL-HLS deployment to augment their existing WebSockets delivery system. 拥有多种可用的传输技术可确保在目标受众使用的各种网络环境和操作系统中成功地播放流.  

WebRTC

As Adobe’s Flash technology and its RTMP streaming playback disappeared from the web and native app realms, a new real-time protocol came about: WebRTC (Real Time Communication). This new protocol promised to add real-time audio and video streaming to web apps using HTML5 standards. 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几乎可以提供任何类型的二进制“数据”。, 比如音频或视频包, over a real-time bi-directional socket between a client such as a web app running in a browser and a server. 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.

更重要的是, WebSockets have been around for a long time! 该规范于2008年首次引入, and by 2011, every major browser vendor supported both insecure WebSocket (ws://) and secure WebSocket (wss://) protocols. The latter protocol uses standard TLS encryption just like HTTPS connections do in the web browser. 在安全WebSocket连接之上构建服务的供应商可以对基于浏览器多年实现的可靠技术充满信心. This simple point can’t be said of other technologies used to stream low-latency content.

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. 如前一节所讨论的, WebRTC and WebSockets establish bi-directional communication between the client and server, 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, here are five reasons for choosing a WebSockets streaming solution over a WebRTC one:

• Scalability: Typically, WebSockets server technology is easier to scale across the cloud. 从网络和跨区域的角度来看，使更多的WebSocket边缘到WebSocket起源要比WebRTC简单得多.
• Firewalls: WebSockets use the same ports as other web traffic: usually TCP port 80 for insecure traffic, 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, particularly if the traffic is traversing mobile carrier networks with asymmetrical NAT (Natural Address Translation). WebRTC需要使用另一层传输, TURN, 或在NAT周围使用中继进行遍历, to do exactly that: get around the problem of NAT environments.
• Cost: 使用WebSockets的服务在云中运行和维护的成本通常比其他竞争的实时技术(如WebRTC)要低. This lower cost usually equates to lower costs of WebSocket streaming vendors compared to WebRTC vendors.
• 编解码器的一致性: 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上需要考虑的变量更少. This ease of use means faster development time, faster testing, and faster deployment. 

Vindral’s core streaming solution is based on WebSockets technology, 即将对LL-HLS提供支持. In the next section you’ll learn why Vindral’s implementation is appealing for one-to-many live streaming deployments.

为什么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架构: How are you going to scale in real time the necessary edge servers from a given origin source?
• 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? 您将如何管理音频和视频缓冲?
• 编码规范: Which codecs will you support for ingest and playback? How will properties of selected codecs be controlled to provide a superior viewing experience?
• 代码转换实现: 大多数流媒体解决方案需要考虑自适应比特率播放，以便内容在各种网络条件下流畅且不间断地播放. How will transcoding resources be created and managed? Do you build your own custom encoder solution or rely on another service? 

These items are just the starting point for considering your own custom built streaming solution. 当你得出结论，寻求一个基于WebSockets技术的一体化流媒体CDN比自己构建更好, you’re now comparing vendors offering an ultra latency solution. 

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

In my own independent testing of Vindral against competing vendors, I found Vindral to demonstrate superior performance with playback resiliency and playback responsiveness.

回放弹性

The first “wow” factor I experienced with Vindral was how well it performed under low or starved bandwidth conditions. Using FFmpeg as an RTMP encoder generating a 1080p 30fps 8Mbps stream into Vindral and other competitors, 我发现使用Vindral的WebSocket平台的播放器逻辑在连接速度低于源比特率的情况下始终提供更流畅的播放体验. Using NetBalancer as a bandwidth throttling tool to simulate 4G and 5G connection conditions, Vindral playback and performance were consistent across devices. 

而我只测试了1080p播放, higher resolutions like 4K or 8K should always be tested and proven before committing to specific deployments, as these resolutions will likely fit into your long term roadmap. 在支持4K和HDR播放的基础上, 在今年的IBC展示会上, Vindral’s team demonstrated a tech preview of 8K streams working just as exceptionally as other content. 

With constricted network conditions such as those that might exist over a VPN or privacy guard network software, Vindral again performed consistently across devices and browsers. Some WebRTC implementations that were tested could not establish connection or playback of the test stream, likely due to lack of a TURN fallback that would work over more strict network rules.

回放反应

Vindral’s embedded player also performed well in other performance categories, including: 

• 第一帧时间: Player initialization and start times were exceptionally fast, 通常在300到600毫秒之间, 低至200毫秒. 客户可以在Vindral门户的Analytics部分查看此统计信息和其他信息(参见图2)。.
• 缓冲和同步控制: Minimum and maximum buffer times for playback could be adjusted easily with variables passed to the embedded player, 1秒的缓冲时间在全帧速率下流畅播放，在测试设备之间的变化在100ms以下.
• 自适应比特率: Vindral的摄取服务将源流转换为Vindral门户帐户的Transcoding Profiles部分中指定的形式. 播放过程中的手动切换是无缝的, and simulated bandwidth throttling didn’t interrupt playback during quality switches.

Figure 2: Vindral会话的分析概述

Cost

作为我对温德尔尔的回顾的一部分, I presented past client engagements and deployment strategies to the Vindral team. 通常, Vindral’s cost for the same target audiences and stream qualities was 50% less than current costs from other vendors. Vindral also offers a flexible business model and custom pricing specific to your deployment needs. If you’re using next gen codecs such as AV1, you’ll benefit from lower traffic volume as well.            

Next Steps

那你下一步打算怎么办? When you’re ready to switch from your current streaming deployment to Vindral, 你需要考虑什么? I advise any of my clients to evaluate a new technology or service as objectively as possible: 

• 实施快速概念验证(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. 供应商成本可能因摄取费用而有很大差异.
• 监控性能: Establish procedures to measure the metrics that matter to you for the viewing experience, 并根据需要跟踪指标. 

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

vindral.com

这篇文章是赞助内容