它将一切粘合在一起：对 SRT 忠实用户 Marc Cymontkowski 的采访
SRT 在 Video Transport 的开发中发挥了重要作用 并且也可以在我们的 video SDK 中使用 。 我有机会在 IBC2019 上与 Marc 进行了一次精彩的对话，我从我们都参与为视频行业创建 DirectShow 过滤器的日子就认识了他。 我们讨论了 SRT 是如何创建的、为什么它是开源的以及未来的路线图。
您能给我们介绍一下 Montivision 时代的背景以及您是如何参与 Haivision 和 SRT 的吗？
好，当然。 我在 2002 年开始了 Montivision 的想法，当时我作为自由职业者为一些需要机器视觉生产的公司工作，例如，对传送带进行质量控制。 我寻找使视频处理独立于采集卡的方法（到每个采集卡都有一个 SDK 时）。 我发现 DirectShow 是实现这一目标的一种方式，并创建了 DirectShow 组件来为工业世界提供机器视觉。
我们构建了带有 UI 和大量视频处理组件选择的 Montivision 开发工具包，您可以将配置导出到 ActiveX 控件中，以便在应用程序中使用。 那很好。
然后，随着时间的推移，我们接到了来自电影和广播行业的人的电话，他们问，既然你们在使用 DirectShow，是否也可以构建一个标准转换组件？我说，我们可以，因为信号处理是我的背景。所以我写了一个用于标准转换的 DirectShow 过滤器。我把它寄回给伦敦的客户，我接到一个电话，他们说，它似乎工作得很好，但出了点问题。当我问出什么问题时，他们说：太快了。这是我接到的最酷的电话：如果算法太快，你为什么要抱怨？那家伙说，根据数学，你不应该能够在不牺牲质量的情况下以每秒 3-4 帧的速度运行。他们想让顾问决定。所以我飞到伦敦，他们将一个昂贵的硬件转换器连接到一个屏幕，将我们的软件连接到另一个屏幕，独立顾问在两个屏幕上看了一会儿，最后指向显示 MontiVision DirectShow 输出的屏幕筛选。
那天我们决定把更多的精力放在广播上。 我们为这个特定的客户开发了很多 DirectShow 过滤器，但也从广播领域吸引了新客户。 然后，在 2005 年，来自奥斯汀的 Kulabyte 创始人给我们打电话。 那些家伙超级有创意，和他们一起工作很酷。 他们对 OTT 编码器有所有这些想法，但不是 C++ 软件开发人员。 他们需要一个非常特殊的自定义 DirectShow 过滤器，并询问我们是否能够构建它。 我们做到了，并且基本上在 2010 年之前完成了整个编码器管道，当他们决定使用 Linux 时，我们必须重新设计整个东西以使其独立于平台。
在重新设计的过程中，Haivision 开始与 Kulabyte 就收购事宜进行交谈，并且在流程结束时，他们意识到他们需要这些来自德国的人。 首席技术官来到德国，我们很快就认为我们可以很好地合作。
那是技术收购还是人才收购？
两者兼而有之，因为如果没有 MontiVision，就不会有我们今天所知的 Kulabyte 编码器。 Haivision 需要开发编码器引擎的人员才能进入 OTT 领域。
Haivision 始终关注嵌入式设备、MPEG-TS 端到端、低延迟、高质量。 他们已经意识到，他们需要一个 OTT 产品来扩展客户的覆盖范围，以便通过 CDN 进行大规模交付。
那么，Haivision 原来是一家运输公司？
完全。 Haivision 最初是做视频会议，非常低延迟的视频传输。 然后该业务扩展到其他垂直领域，但重点始终是高质量低延迟端到端视频解决方案。 我们总是犹豫要做广播，因为我们的编码器当时缺少一些典型的广播要求，但客户喜欢他们的贡献馈送，所以这个领域成为主要支柱之一。
那么，这是远程生产想法兴起的时候吗？
Exactly.
那是通过公共互联网完成的吗？ 还是需要专线？
那已经是公共互联网了，因为那时我们已经有了 SRT。 SRT 最初创建于 2012 年，并于 2013 年首次亮相。当我 2011 年加入时，Haivision 评估了第三方公司的专有技术。 我们喜欢这项技术，但无法达成可接受的商业协议。
所以，有一天我们的 CMO 和 CTO 来找我说，Marc，我们需要 SRT。 我当时想，什么是 SRT？ 安全、可靠的传输：它能够以极低的延迟在公共互联网上发送加密的 MPEG 传输流。
我有一些通过公共互联网将符合 DVB 标准的视频传输到卫星传送点的经验，但是在将信号输入传送点之前，我们必须使用长缓冲区对信号进行平滑处理。 它必须是一个完美的定时信号，因为你知道 DVB 真的很挑剔。 所以整个想法是基于一个名为 UDT 的库。 我们使用巨大的 10 秒缓冲来平滑信号。 这种 UDT 的东西在公共互联网上运行得非常好，但延迟非常高。
我想，要改变这一点，我们需要在发送方机器上捕获系统时间戳，将其放入标头中，并使用它在接收方重新创建信号形状。
因为我知道在蒙特利尔我们有一些核心网络人员，我相信他们会帮助我实施它。 所以我去找了我认识的最聪明的人之一，和他坐下来，解释了我想用 UDT 库做什么。
在我解释完一切之后，我可以从他的反应中感觉到他在想“嗯，愚蠢”之类的东西。 所以我飞回德国，真的很沮丧。 但是，几周后，我收到一封电子邮件，上面写着“……好吧，也许吧。 我尝试了一些东西，它可以工作。”
在 IBC 2013 上，我们展示了从 IBC 外的酒店套房利用公共互联网上的 SRT 到展厅的现场 HEVC 编码，在那里我们有一个带屏幕的小展位，我们正在展示在酒店进行的现场采访。当人们说它可能是假的时，我们让他们拿起手机打电话给面试官，看看他是如何拔出手机的。
就这样开始了，我们将 SRT 放入我们所有的产品、编码器中、解码器、网关、媒体平台。突然间，我们能够连接全球所有的点。我们把它带到了一个阶段，我们的媒体网关成为这个后端路由服务，我们可以在不同的云上启动它并设置端到端路由。现在，我们正通过无服务器云架构将其带入下一个阶段——同样的概念，但有一个基于 Web API 的中央 UI。全球路由工作流程，扩展到通过物联网控制集成的设备。因此，您可以创建从地球一侧的设备通过 Internet 到地球另一侧的设备的端到端路由。或者到云中的目的地。
SRT Hub？
没错，这就是 SRT Hub。
在您对 SRT 的设想与实际完成之间——有什么区别？ 这个想法有发展吗？
我的意思是，这个想法是从 A 到 B 获取数据，一开始它是单向的。 当它奏效时，人们立即表示，通过同一渠道获取数据会很棒。 好的，应该是可能的——所以我们把它做成了双向的。 然后，UDT 已经有了一些东西，即多路复用功能。 它有什么作用？ 它通过 UDP 多路复用流。 哦，酷，让我们激活它。 因此，我们进行了所有代码更改以使其正常工作，现在您可以在一个 UDP 端口上运行多个双向 SRT 连接，这就是我们所说的 SRT 多路复用。
然后接下来的事情：有这种双向连接很好，但我怎么知道哪个流是哪个？ 标头中有一个标识符。 但是一个简单的标识符意味着我需要一个数据库来将此标识符转换为客户 X、流 Y 等。 两个月前，我们提出了我们所谓的内容访问规范，它允许您在 SRT 握手中添加用户名、流名称和模式（发布/请求）。 现在，侦听器套接字可以对传入的 SRT 连接做出反应，决定是要允许还是拒绝连接，还可以选择客户分配的加密密码。
验证？
是的，这是一种身份验证方式。
我们在 NAB 2019 的实验分支中引入的另一件事是数据包过滤器 API，它允许您编写用于发送方和接收方的自定义网络数据包过滤器，我们使用它来为协议添加 FEC 支持。 我们放置 FEC 的原因并不是每个人都想要 FEC。 但是我们在广播市场工作，广播公司很早就知道 FEC。 由于我们面临担忧和批评，我们为 SRT 添加了 FEC 支持，并让人们可以灵活地使用仅 ARQ、仅 FEC 或两者结合使用。
但没必要，你是说？
仅在特定用例中才有必要。 一些宽带客户告诉我们，如果他们想通过专用的优质超长距离链路传输非常高的比特率流，例如美国到澳大利亚，FEC 为他们提供比 ARQ 更低的延迟。 但是现在有了语音只做ARQ，重传包，可以选择纯FEC，也可以把FEC和ARQ结合起来，这样如果FEC不能恢复丢包，ARQ仍然可以重传丢包。
您将如何细分使用 SRT 的区域？ 有什么意想不到的应用吗？
我们倾向于称它为胶水，因为 SRT 将所有东西粘合在一起。 人们仅将它用于未压缩的 AES67 音频。 德国有一个人，他在端点上进行机器分析，然后通过 SRT 发送元数据。 其他人通过在其上使用自定义多路复用器进行多路复用，在一个 SRT 连接上创建多个视频链接。 有很多不同的用例……曾经有人告诉我：如果 TCP 知道将来它会主要做视频，那么它就会像 SRT。 很好的描述。
你能谈谈开源的想法吗？ 你为什么做出这个决定？ 目标是什么？
我们知道 SRT 工作得非常非常好。 因为我们使用编码器、解码器、网关大量交付它。 合作伙伴询问他们是否可以从我们那里获得协议许可，而客户则询问与他们合作的其他公司是否能够添加 SRT 支持。 与此同时，许多专有解决方案涌现出来，其中很多。 我们有两个选择，要么我们最终实施所有这些，要么我们大力推动并尝试统一市场。 在公司内部获得每个人的支持并不容易，因为我们即将放弃一些独特的东西。
但是在我们这样做之后，我们获得了如此多的认可，因为我们围绕着我们大力支持的协议创建了一个生态系统。 突然间，我们引起了市场上更大的参与者的注意。 微软成为该协议的大力支持者，因为他们喜欢我们正在做的事情。 突然间，这个鲜为人知的小众玩家 Haivision 在 IBC2019 上成为了所有人的话题。
但是，显然，存在竞争的因素。 对于他们的一些客户来说，这可能是编码器和解码器的销售，对吧？
竞争总是存在的，但问题是，市场对于许多公司来说已经足够大了。 我们正在使用 SRT Hub 重复该模式。 这次不是开源，而是一个开放的生态系统。 我们在云端构建了这个媒体路由服务。 我们有 hublets 的概念，您可以在其中插入我们的系统。 如果第三方编写 hublet，他们的服务可以用作路由服务的一部分。 我们提供路由服务并创建这个广播生态系统，您可以在其中连接云中的各种解决方案。
因此，据我了解，您不是与每个人的专有协议竞争，而是创建了一个每个人都可以使用的协议。 你已经扩大了市场。 通过扩大市场，您获得的收益比使用专有解决方案所获得的收益更多。
正确。
但我的另一个问题是，为什么要开源？ 因为，例如，NDI® 几乎在做同样的事情，对吗？ 他们正在为 NDI 创建一个市场，但它是专有的、封闭的、可以免费使用的。 你为什么选择开源？ 这对你有什么好处吗？
一个巨大的好处是可信度。 我经常向人们提到的是，如果你想围绕一个开源项目建立信誉，那么你需要对它保持开放和诚实。 这就是为什么从第一天开始，所有功能都首先进入协议。 有时有传言说 Haivision 有一个秘方，我们运行一个定制的 SRT。 这不是真的。 例如，Haivision 正在使用 SRT 进行网络自适应编码。 所以编码器正在做动态的东西？ 是的，它确实。 但这不是 SRT：我们的编码器查看协议生成的统计数据，并使用这些统计数据来调整编码器比特率——每个人都可以做到。 那里没有秘密酱汁。 那不是协议。 随着时间的推移，我们获得的可信度越高，人们就越信任我们，我们可以合作的生态系统就越大。
一开始，很多人告诉我他们不明白我们为什么要开源 SRT。 他们假设我们会在某一时刻要求获得许可，或者我们会有隐藏的来源，这提供了某些优势。 我再也听不见了。 人们明白我们对此很认真，这对我们来说非常重要。
但是你会为硬件制造商做授权吗？ 或者你们的开源许可证是否允许我创建一个包含 SRT 的硬件设备？
是的，您可以将协议放入您的设备中。
所以，它与 NDI 不同……
SRT 是一个框架，就像 FFmpeg：拿它做任何你想做的事。 唯一的要求：如果您有改进，请回馈。
效果如何？ 那里有数百人贡献？
一开始它很慢。 人们在看，很多人克隆代码，研究它，但贡献正在缓慢上升。 我会说第一个突破是去年在 IBC 上，然后是今年在 NAB 上的另一个突破。 到目前为止，我们已经有大约 50 个协议贡献者。 现在反馈的数量和质量正在稳步提高。
因此，有 50 人参与的事实实际上是在帮助您改进产品，而不是增加管理开销……
对，让它更加稳固
在接下来的几个月中，您认为该协议的三大改进是什么？
目前我们已经有一段时间没有弹药了，因为我们在上个月向协议中加入了太多东西，这太疯狂了。 我在开源面板上宣布的下一件事是这个用于套接字组的实验性分支，基本上是网络链接绑定。 这些令人兴奋，因为这个非常简单的概念非常灵活，因此非常强大。 您可以将多个独立的 SRT 连接添加到一个套接字组中，这个套接字组会突然处理所有连接，同步它们并与所有连接进行通信。 因此，您将数据发送到组中，然后到达目的地，然后有另一个组接收器，然后您会得到一个流。
这让你可以说，现在我希望所有这些链路完全冗余，通过所有链路发送所有数据，并在接收端有一个 SMPTE 2022-7 无缝保护倒换接收器。 所以基本上，先到先得，无论数据包先到，你都会收到它，然后 SRT 进行定时恢复并像往常一样输出信号。
其次，我们实现了主备方案，在链路之间进行无缝切换。 在SRT缓冲时间范围内，协议检测主链路是否有问题，切换到备用链路。 因此，您不再通过所有链接发送所有数据，而是仅发送一次数据。
这是否意味着这些不同的链接在 Internet 上有不同的路由？
是的，您将拥有不同的网络提供商、不同的网络类型或至少有两条不同的互联网路由。 团队正在研究的第三个套接字组功能是绑定。 控制多个链接后，您可以将数据拆分到多个链接中。 因此，您可以通过组合不同的链接来获得更高的吞吐量。
这是一项艰巨的任务，还有很多工作要做，但我们希望在 NAB 2020 上推出 SRT 1.5 版。但这是可行的，因为例如，仅主/备用链接就是一个非常复杂的主题。 您需要协议中的智能来决定何时切换。 我们需要进行大量的实验，这就是为什么我们把它放在一个实验分支中。 人们可以接受它并帮助我们在不同的网络上运行它，告诉我们有什么问题，给我们反馈，帮助我们验证，所以希望它能够在 NAB 2020 上发布。
您在 SRT 运动中的角色是什么？ 你是在设计架构，还是在推广？
我在社区中收集想法和愿望，提出很多想法，并与我们组织内的人交谈，看看他们需要什么。 冗余话题多年来一直很热门，随着时间的推移，我们在实验室中进行了不同的实验。 但这不是一个无关紧要的话题。 开发人员想出了一个非常酷的解决方案，但是 CPU 利用率太高，以至于您无法在嵌入式设备上运行它。 然后他们想出了另一个解决方案，它非常低级，超轻量级，但不够可靠。 而现在，通过套接字组模型，我们认为我们找到了一个很好的平衡点。 这就是我正在做的事情，试图成为 SRT 大使。
您是否面临任何竞争？ RIST 协议？
RIST 计划开始于我们开源 SRT 并且我们是工作组成员的时候。 该小组有一个明显的趋势，即依赖现有标准，以 RTP 为基础并在其之上构建，这对于 RIST 的简单配置文件来说是正确的。 因此，您可以将 RIST 简单配置文件流发送到现有的 RTP 接收器。 一旦你进入主配置文件，因为你有加密、多路复用和其他功能，这种互操作性就会中断。 最后，主要配置文件是一个与 SRT 没有太大区别的协议。
它们之间的区别在于，SRT 是一种代码库。 这是一个社区项目。 每个人都使用相同的代码，而且它是由实现驱动的。 RIST 是标准驱动的。 如果你是一个大的广播公司，你可能有一个开发团队自己实现它，对吧？ 所以一些大人物可能会这样做。 但是许多较小的参与者没有工程能力来实现他们需要的每个协议并随着时间的推移对其进行维护。 他们可以采取 SRT 并且它有效。
无论哪种方式都是完全有效的。 我不认为两者都存在问题。 RIST 小组非常关注广播市场。 SRT已被带入各种领域。 人们将它用于物联网连接、元数据交换、通信协议、未压缩数据以及许多显然用于通过公共互联网发送 MPEG 传输流。
这就是为什么我称它为胶水！ 无论您想粘合什么，都可以将 SRT 放在两者之间。