新时代对数据传输速度和交付可靠性提出了新要求，而传输的内容量也在不断增长。当通过公共互联网、网络和内容提供商交付高清视频时，不可避免地会遇到以下问题：
- 无法保证交付，接收方的视频可能会丢失帧、不同步或包含伪影或冻结帧
- 许多解决方案具有高延迟，不能用于现场直播
- 希望能够使用任何带宽的链路，甚至多个链路
- 内容需要防止被盗
- 实施需要简单，而协议必须与其他硬件和软件兼容。
许多供应商、内容提供商、网络提供商和广播公司都感到茫然：他们应该在编码器、播放器、机顶盒和播放系统中支持和实施哪些协议？同时，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）。
图 1 – 成功恢复所有突发丢失率为 86% 的数据包
目前正在为该协议开发一个新的增强型/高级配置文件。预计它会包括改进的带宽管理、自适应比特率、无损压缩、创建的广播链路的优化管理、在 HbbTV 和 ATSC 3.0 中实现的混合广播支持，以及其他内容（图 2）。 Advanced Profile 的发布计划于 2021 年发布。
图 2 – RIST 路线图
结论
兼容性一直在视频行业中发挥着至关重要的作用。为了实现兼容性，构想并批准了各种标准，这些标准可以将不同的供应商聚集在一个通用的基础架构下，而专有技术总是有可能成为项目瓶颈。
以所有合作伙伴、客户、网络提供商、后期制作公司和观众都可以访问的形式制作内容是任何广播公司的关键要求。但随着时间的推移，广播公司的需求增加，不仅涉及兼容性，还涉及可用性、延迟、带宽最小化，同时保持广播 UHD 内容的能力、在有损公共网络上广播、安全性、授权以及易于配置和管理。为了响应这些需求，新技术和协议不断涌现，包括本文中比较的两种技术和协议。这两种协议都已被广泛使用：在撰写本文时，SRT 联盟拥有 450 多家成员公司，而 RIST 论坛拥有 130 多家。然而，谁将在中长期内占领市场尚无定论-学期。也许有一天 SRT 和 RIST 将合并为一个协议，因为尽管存在差异，但它们服务于相似的目的并且在功能特性上彼此接近。
下表提供了 SRT 和 RIST 的比较，总结了上述所有内容。
| 功能性 | SRT v1.4 | RIST（主要简介） |
|---|---|---|
| 基于UDP | 是（UDT） | 是（RTP） |
| 由...制作 | 单一公司 | 公司集团 |
| 点对多点广播 | 不 | 是的 |
| 丢包重传机制 | 是的 | 是的 |
| 防火墙旁路机制 | 是的 | 是的 |
| 支持所有编解码器 | 是的 | 是的 |
| 参考实现（开源库） | 是的 | 是的 |
| 去除填充/填充（空数据包） | 不 | 是的 |
| 不同供应商实现之间的兼容性 | 是的 | 是的 |
| 前向纠错支持 | 是的 | 是的 |
| 安全/加密 | 键控 | DTLS 或 PSK |
| 备份 | 不 | 是（根据 SMPTE-2022-7 绑定和无缝切换） |
| 验证 | 键控 | 基于证书或 TLS-SRT |
| 上损失阈值 | 12% 到 15% | 40% 至 55% |
| 高比特率广播 | 是的 | 是的 |
| 现有社区 | 是的 | 是的 |
| 与早期标准的兼容性 | 不 | 是的 |
| 单个端口的连接多路复用 | 是的 | 是的 |
| 数据包重传期间的带宽节省 | 不 | 是的 |
| 低延迟 | 是的 | 是的 |
| 抖动 | 是的 | 是的 |
| 广泛的市场占有率 | 是的 | 是的 |
| 与传统解决方案的兼容性 | 不 | 是的 |
| 本机延迟测量功能 | 是的 | 是的 |
| 隧道（GRE） | 不 | 是的 |
以下是开源 RIST 库的主要开发人员之一 Gijs Peskens 关于他对 RIST 和 SRT 比较的看法的评论：
“我认为我喜欢 RIST 协议的最大原因是因为它非常简单。我将能够与某人坐下来并能够在不到半小时内解释核心简单配置文件协议，如果他们对视频流和网络有很好的了解，我猜会更少。从操作的角度来看，我认为我们使用 RIST 的主要原因是简单的配置文件支持多播（当时 SRT 没有，我不确定现在是否支持），并且它向后兼容 plain RTP 接收器。
为了更深入地研究协议，RIST 从一开始就被设计为视频传输协议，主要是 MPEG-TS，它基于视频传输/网络中使用的现有技术，如 RTP 和 GRE，并使用自适应重试请求向发送方发送数据包丢失信号。
关于我帮助维护的 libRIST，我们刚刚发布了我们的第一个稳定版本，并且正在为 0.3 奠定基础，它将具有全双工通信、基于证书的访问控制等功能”。
尝试 Elecard CodecWorks - 支持 SRT 的实时编码器和流媒体。 RIST 支持即将推出。
作者
维塔利·苏图里欣
自 2015 年起担任 Elecard 集成和技术支持部门负责人。Vitaly 在信息技术领域拥有超过 15 年的经验。他负责支持最重要的 Elecard 客户，例如 MTS、Moscow Metro、Innet、ReadyTV。 Vitaly 负责 2017 年国际足联联合会杯和 2018 年圣彼得堡国际足联世界杯的 IPTV 和 DVB 广播。
2021 年 6 月 29 日