新时代对数据传输速度和交付可靠性提出了新要求，而传输的内容量也在不断增长。当通过公共互联网、网络和内容提供商交付高清视频时，不可避免地会遇到以下问题：

• 无法保证交付，接收方的视频可能会丢失帧、不同步或包含伪影或冻结帧

• 许多解决方案具有高延迟，不能用于现场直播

• 希望能够使用任何带宽的链路，甚至多个链路

• 内容需要防止被盗

• 实施需要简单，而协议必须与其他硬件和软件兼容。

许多供应商、内容提供商、网络提供商和广播公司都感到茫然：他们应该在编码器、播放器、机顶盒和播放系统中支持和实施哪些协议？同时，RIST 和 SRT 等低延迟、有保证的数据传输协议近来广受欢迎。但是你应该选择哪一个呢？

RIST 和 SRT 有什么共同点？

这两种协议都是为通过公共互联网网络进行低延迟视频传输而设计的。 SRT 最初由 Haivision 开发，用于他们自己的编码器和解码器。它于 2017 年作为开放式实时视频传输协议发布。请注意，Haivision 不仅是 SRT 的开发者和 SRT 联盟的创始人，而且还是 RIST 论坛的成员，该论坛是视频服务论坛的一部分。

2017年也是RIST开发的起步之年。许多公司在他们的产品中使用了各种 RIST 实现，但他们的解决方案并不相互兼容。

RIST 和 SRT 具有相同的加密级别，都支持高比特率流媒体和前向纠错 (SMPTE 2022-1)。这两种协议都支持长达 256 位的预共享密钥和自动重复请求 (ARQ)，可以绕过防火墙，并允许在交付可靠性和延迟之间进行权衡。

今天，这两种协议都作为开源库实施，这有助于加速和简化广播的启动，并避免依赖特定供应商，而不是使用像 Zixi 这样的专有解决方案。

SRT 和 RIST 存在于许多流行的解决方案和框架中，例如 AWS Media Connect、Nimble Streamer、VLC、gstreamer、ffmpeg 和 wireshark（通过插件）。 librist 和 libsrt 库可用于所有三种主要操作系统：Windows、Linux 和 MacOS。

协议之间有什么区别？

SRT 最初是由一家公司基于 UDT（基于 UDP 的数据传输协议）开发的，UDT 是一种众所周知且经过验证的文件传输协议。 UDT 比 TCP 快得多，并且可以轻松配置。然而，与文件不同的是，媒体数据的体积要大得多，而且很容易丢失。 SRT 在低或中等丢包率下表现出色——比如不超过 10% 到 12%。 SRT 的主要目标是取代亚马逊停止支持的旧版 RTMP 协议，同时浏览器放弃了对 Flash 插件的支持。

RIST 由来自不同公司的专门从事视频内容交付的专家团队共同开发（视频服务论坛和来自不同媒体公司的一组技术代表，后来组成了 RIST 论坛）。 RIST 基于 RTP、RTCP 和 SMPTE-2022 协议（使用 IP 传输）以及其他几个互联网标准 (RFC)。 RIST 最初是为传输视频内容而开发的，并结合了在开发早期开放和专有流媒体协议时获得的大部分经验。 RIST 可以恢复高达 55% 的持续数据包丢失和高达 86% 的短期数据包丢失。

即使是老播放器、转码器、媒体服务器或分析器也可以通过接受 RTP 在基本级别上使用 RIST，但是，它们不支持 SRT。

讯享网

两种协议的授权方法不同。 SRT 仅使用预共享密钥 (PSK)，它提供了可接受的安全级别，但并不适合所有广播公司。 RIST 也使用 PSK，但可以补充 SRP（安全远程密码）协议以提供额外保护。此外，RIST 支持基于证书授权的 DTLS，这是大多数广播公司的基本要求。

对于防火墙绕过，SRT 使用调用者/侦听器握手的概念，无需永久规则配置，并且还具有用于此目的的特殊会合模式。其原理是基于防火墙中的连接监控功能。另一方面，RIST 使用 RTCP 消息绕过防火墙。

丢失数据包重传的方法也因协议而异。 SRT 并不总是适用于窄带互联网链接，因为在高错误率的情况下，它可能会用重新传输的数据包堵塞链接，而 RIST 有能力减少此类重新传输的带宽消耗。 ARQ 在 RIST 中仅使用 NACK 实现，而 SRT 使用 NACK 和 ACK 来确认接收。

SRT 仅支持点对点模式，而 RIST 采用点对多点方法，包括多链路支持和多播实现。与基于一个特定公司的参考实现的开源库的 SRT 相比，RIST 是基于在一组公司的参与下开发的开放规范。 librist 项目有积极的志愿者，他们作为测试人员和技术开发人员做出贡献。

为什么选择SRT？

使用 SRT，丢失的数据包会尽快重新广播，这意味着更高的内容质量和更低的延迟，除非带宽有限。

如今，SRT 已经获得了一定程度的市场份额，并催生了支持该协议并将其用于其解决方案的开发公司联盟。 SRT 是一个开源项目，吸引了相当多的社区。目前，SRT 联盟拥有超过 450 家成员公司，包括最近加入的 AWS、OBS 和索尼。

SRT 也适用于传输大量数据，但效率急剧下降或在丢失率达到 15% 或更高时变得完全低效，这已被各种研究证实。

SRT 在今天仍然比 RIST 更常见，在与潜在环境的兼容性方面更有效。与 RIST 不同，SRT 已经存在于 OBS Studio 和 Wowza 等流行的解决方案中。

SRT v1.5 的发布计划于 2020 年发布，但在撰写本文时仍未发布。在此版本中，开发人员承诺实现绑定、C++11 支持和双向元数据交换，并改进带宽估计和多播支持。

我已经在较早的文章中详细讨论了 SRT 。

为什么选择 RIST？

RIST 支持 IP 组播广播，可节省大量流量和网络资源。 RIST 可以并行广播多个流（多流多路复用），只需要一个 UDP 端口。基于广泛使用的 SMPTE 2022-7 标准，在通过备份链路传输的流副本之间支持无故障的无缝切换。在接收端，RIST 将多个流合并为一个公共流（链路聚合/绑定）。

由于 RIST 是基于 RTP 的，绝大多数接受 RTP 协议的设备在一定程度上也可以与 RIST 一起工作（除了处理数据包重传的能力和 RIST 的其他杀手级特性）。

RIST 具有减少数据包重传期间流量以实现稳定广播的能力，并通过丢弃空数据包（填充/填充）来消除流量开销。 RIST 针对通过 RTP 标头扩展传输高比特率视频进行了优化，它允许将数据包编号的范围从 16 位扩展到 32 位。 RIST 也被认为具有更好的安全性，因为它同时支持 PSK（预共享密钥）和基于 DTLS 证书的加密，后者被认为更安全并被大多数银行使用。 RIST 可以在 100% 的开销下从高达 25% 的损失中恢复，在 200% 的开销下从高达 50% 的损失中恢复。在 2020 年虚拟 NAB 贸易展的测试期间，RIST 被证明可以从 86% 的突发丢失中恢复，并成功交付所有数据包（图 1）。