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

今年5月，我在流媒体东大会上做了一次演讲, 我回顾了目前市场上可用于实时流需求的低延迟选项—主要是从内容提供商和提供这些堆栈的供应商可用的各种技术堆栈的角度. 从最低延迟到最高延迟, 这些选项包括WebRTC, WebSocket, CMAF的变化, HLS(苹果的HTTP Live Streaming方法)和DASH.

对于任何有直播业务需求的利益相关者, 无数的选择可能会让人不知所措，而且很容易被误解. 选择错误的解决方案或方法可能会给客户带来不一致的结果, 以及昂贵的技术栈改造. Moreover, 从一个版本到下一个版本，这些技术堆栈中的许多都经历了巨大的变化, 使用来自浏览器厂商的混合实现.

进入RealSprint最新的低延迟流媒体CDN解决方案: Vindral. Vindral使用WebSockets技术作为其一秒内实时内容交付的基础. In this article, 我解释了为什么WebSockets技术可能是直播的最佳选择，以及为什么Vindral在低延迟市场中被定位为首屈一指的CDN.

Note: 为了讨论的目的, 我将关注一对多业务需求, 一个源流需要与许多订阅者实时共享, 区域性或全球性.

流媒体技术入门

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

HTTP流:CMAF, HLS和DASH的变化

流传输的圣杯之一是能够使用现有的HTTP扩展架构来提供高容量和可靠的服务. 简而言之，如果您可以使用HTTP流量的cdn扩展一般web内容，您就可以 should 能够对流媒体视频使用相同的缩放机制. 对于流播放中的延迟，有几个因素会起作用. 通过TCP传输的HTTP数据包的往返时间(RTT)会给流增加一些延迟. HTTP缓存也是CDN架构的主要组成部分, 根据定义，缓存需要写入和存储内容，这也增加了延迟. More importantly, CMAF, HLS, 和DASH都是清单驱动格式，其性能在很大程度上取决于在web应用程序或设备应用程序中运行的视频播放器代码. 视频播放器必须不断地获取流的“内容表”——通常深度不止一层——然后才能开始加载和播放参考流的片段. 段持续时间也是决定这些格式延迟的关键因素. 由于此类流是通过HTTP或HTTPS协议在标准TCP端口上提供的, 网络防火墙通常不会拒绝这种通信. 因此，您可以放心，内容的播放问题将很少受到关注.

在过去的几年里, Low Latency HLS, or LL-HLS, 已经由苹果和其他主要供应商(包括Vindral. 与典型的HTTP流格式相比，LL-HLS的核心改进是进一步减小了数据块或数据段的大小——视频播放器可以更可预测地获取较大数据块或数据段的最新部分，而无需等待其他部分预加载. 虽然该规范是对传统HLS部署的改进, 跳过段或帧以保持与实时流的同步并不容易. 在我用LL-HLS做的早期测试中, 随着播放时间的增加，直播流经常会偏离实时同步. 大多数现成的网络视频播放器需要一个特定的LL-HLS实现才能工作. Vindral正在积极开发他们自己的LL-HLS部署，以增强他们现有的WebSockets交付系统. 拥有多种可用的传输技术可确保在目标受众使用的各种网络环境和操作系统中成功地播放流.

WebRTC

随着Adobe的Flash技术及其RTMP流媒体播放从网络和本地应用领域消失, 一种新的实时通信协议应运而生:WebRTC(实时通信). 这个新协议承诺使用HTML5标准为web应用程序添加实时音频和视频流. WebRTC可以在各种交付场景中工作, 包括P2P (Peer to Peer)，客户端直接向对方发送报文, SFU(选择性转发单元)，服务器在客户端之间代理数据包, MCU(多点控制单元)，其中服务器合并来自客户端的多个音频和/或视频上游数据包，为每个连接的客户端创建单个下游. 在webbrtc客户端连接到服务器并协商其到内容的路径之后, 音频和视频通过TCP和/或UDP端口传输, 理想情况下是后者——尤其是在延迟低于一秒的情况下. 客户端接收到的WebRTC数据包具有最小的缓冲, 并使用UDP传输, 数据包可以更容易地丢弃，以跟上实时回放.

因为WebRTC的初衷之一就是实现实时音频, video, 以及多个客户端之间相互共享数据的数据(例如.g. 音频/视频会议), 重点是保持交互尽可能实时, 延迟可以忽略不计. As a result, 视频流的质量可能会波动，以保持实时播放——播放质量的控制可能不在播放器技术的掌握之中，而是潜在的本地浏览器api. 视频播放可能无法保持高比特率, high quality, 在webbrtc上实现高帧率，同时实现超低延迟.

WebSockets

WebSockets如何适应流解决方案? In short, WebSockets几乎可以提供任何类型的二进制“数据”。, 比如音频或视频包, 通过客户端(如浏览器中运行的web应用程序)和服务器之间的实时双向套接字. 客户端可以接收数据，也可以将信息发送回服务器. 许多类型的应用程序可以构建在WebSockets技术之上, 从实时聊天到低延迟流媒体视频和音频.

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

WebSockets上音频和视频内容的播放和多比特率控制并不是由web浏览器中的本地媒体api提供的. 大多数WebSockets视频播放是特定于依赖于HTML5媒体源扩展(MSE)的定制播放器代码库的。. 每个WebSocket流媒体供应商都有一个专有的内容交付系统.

WebSocket技术的商业案例

对于不基于HTTP或HTTPS的低延迟流，如HLS或DASH, 两个最大的竞争者是WebRTC和WebSockets. 如前一节所讨论的, webbrtc和WebSockets在客户端和服务器之间建立了双向通信, 支持对发送和接收数据的更精细和控制, 比如丢帧, 往返时间(RTT), and much more.

那么如何在webbrtc和WebSockets之间进行选择呢? 显然，它们是延迟最低的两种选择，但哪一种“更好”呢?? 虽然每个用例和业务需求可以是唯一的, 以下是选择WebSockets流解决方案而不是webbrtc流解决方案的五个原因:

Scalability: 通常，WebSockets服务器技术更容易跨云进行扩展. 从网络和跨区域的角度来看，使更多的WebSocket边缘到WebSocket起源要比WebRTC简单得多.
Firewalls: WebSockets使用与其他web流量相同的端口:通常TCP端口80用于不安全的流量, TCP端口443用于安全流量. 大多数允许网络流量的防火墙也将允许WebSocket流量, 使您的内容更容易获得不断增加的锁定网络. WebRTC, on the other hand, 通过互联网进入局域网环境会有困难吗, 特别是当流量通过带有非对称NAT(自然地址转换)的移动运营商网络时。. WebRTC需要使用另一层传输, TURN, 或在NAT周围使用中继进行遍历, 要做到这一点:绕过NAT环境的问题.
Cost: 使用WebSockets的服务在云中运行和维护的成本通常比其他竞争的实时技术(如WebRTC)要低. 与webbrtc供应商相比，WebSocket流媒体供应商的成本通常更低.
编解码器的一致性: WebSockets可以使用特定的视频和音频编解码器，这些编解码器在web浏览器中运行的客户端应用程序之间是一致的, 不像WebRTC，它可能会依赖于浏览器供应商青睐的特定编解码器.
开发者学习曲线: 一对多WebSocket服务的sdk更容易实现和控制, 因为在WebRTC上需要考虑的变量更少. 这种易用性意味着更快的开发时间、更快的测试和更快的部署.

Vindral的核心流解决方案是基于WebSockets技术的, 即将对LL-HLS提供支持. 在下一节中，您将了解为什么Vindral的实现适合一对多的实时流部署.

为什么Vindral很特别?

在确信WebSockets技术更有可能满足您对超低延迟解决方案的业务需求之后, 你的下一步是确定实现它的路径. 经典的“构建还是购买”困境同样适用于超低延迟流，也适用于产品和软件开发过程的其余部分.

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

摄取架构: 你将如何从你的发布点(如H)中汲取养分.264流媒体设备或应用? 你的摄取需要存在于哪些区域?
Edge-origin架构: 如何从给定的原始源实时扩展必要的边缘服务器?
Video playback: 你将使用什么指标来确定帧数下降, 视频质量切换, 以及在观众之间同步播放? 如何在web应用程序或本地应用程序中实现这些指标? 您的软件开发人员是否精通媒体api和事件处理? 您将如何管理音频和视频缓冲?
编码规范: 对于摄取和播放，您将支持哪种编解码器? 如何控制所选编解码器的属性以提供优越的观看体验?
代码转换实现: 大多数流媒体解决方案需要考虑自适应比特率播放，以便内容在各种网络条件下流畅且不间断地播放. 如何创建和管理转码百家乐软件? 您是构建自己的自定义编码器解决方案还是依赖其他服务?

这些项目只是考虑您自己的自定义构建流解决方案的起点. 当你得出结论，寻求一个基于WebSockets技术的一体化流媒体CDN比自己构建更好, 您现在正在比较提供超延迟解决方案的供应商.

实时流云架构的入口/出口

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

在我自己对Vindral与竞争厂商的独立测试中, 我发现Vindral在播放弹性和播放响应性方面表现出卓越的性能.

回放弹性

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

而我只测试了1080p播放, 在进行具体部署之前，应该始终对4K或8K等更高分辨率进行测试和验证, 因为这些决议很可能适合你的长期路线图. 在支持4K和HDR播放的基础上, 在今年的IBC展示会上, Vindral的团队演示了8K流的技术预览，它和其他内容一样出色.

使用受限的网络条件，例如可能存在于VPN或隐私保护网络软件的网络条件, Vindral再次在不同设备和浏览器上表现一致. 一些被测试的WebRTC实现无法建立连接或测试流的回放, 可能是由于缺乏在更严格的网络规则下工作的TURN回退.

回放反应

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

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

Vindral会话的分析概述

Figure 2: Vindral会话的分析概述

Cost

作为我对温德尔尔的回顾的一部分, 我向Vindral团队介绍了过去的客户约定和部署策略. 通常, 对于同样的目标受众和流媒体质量，Vindral的成本比其他供应商目前的成本低50%. Vindral还提供了灵活的业务模型和针对您的部署需求的定制定价. 如果您使用AV1等下一代编解码器，您也将受益于较低的流量.