为什么要创建SRT？

提示&＃xff1a;本文为译文&＃xff0c;参考https://github.com/Haivision/srt/blob/master/docs/misc/why-srt-was-created.md

Some people have asked us why we’re using the UDT library within our SRT protocol. Actually, some people claimed that SRT is just a slightly modified version of UDT and that UDT is known to be useless for live video transmission. Guess what, the latter is true. UDT has been designed for high throughput file transmission over public networks. However, SRT is far from being a slightly modified version of UDT. I’ll get into the details, but will start with a little bit of history.
有些人问我们为什么要在SRT协议中使用UDT库。 事实上&＃xff0c;一些人声称SRT只是UDT的一个稍微修改的版本&＃xff0c;而众所周知&＃xff0c;UDT对于直播视频传输是无用的。 你猜怎么着&＃xff0c;后者是真的。 UDT是为公共网络上的高吞吐量文件传输而设计的。 然而&＃xff0c;SRT远非UDT的一个稍微修改的版本。 我会讲到细节&＃xff0c;但会先讲一点历史。

Haivision has always been known for lowest latency video transmission across IP based networks, typically MPEG-TS unicast or multicast streams over the UDP protocol. This solution is perfect for protected networks and if packet loss became a problem, enabling forward error correction (FEC) fixed it.
Haivision一直以在基于IP的网络上进行最低延迟的视频传输而闻名&＃xff0c;通常是基于UDP协议的MPEG-TS单播或多播流。 这个解决方案对于受保护的网络是完美的&＃xff0c;如果数据包丢失成为一个问题&＃xff0c;启用前向错误纠正(FEC)可以解决这个问题。

At some point we were getting questioned whether it would be possible to achieve the same latency between customer sites in different locations, between different cities, countries or even continents. Of course it’s possible with satellite links or dedicated MPLS networks, but those are quite expensive solutions, so people wanted to use their public internet connectivity instead. While it’s possible to go with FEC in some cases, that’s not a reliable solution, as the amount of recoverable packet loss is limited, unless you accept a significant amount of bandwidth overhead.
在某些时候&＃xff0c;我们被问到是否有可能在不同地点、不同城市、不同国家甚至不同大洲的客户站点之间实现相同的延迟。 当然&＃xff0c;通过卫星连接或专用的MPLS网络也是可能的&＃xff0c;但这些解决方案非常昂贵&＃xff0c;所以人们希望使用他们的公共互联网连接。 虽然在某些情况下可以使用FEC&＃xff0c;但这不是一个可靠的解决方案&＃xff0c;因为可恢复的包丢失数量是有限的&＃xff0c;除非您接受大量的带宽开销。

After evaluating the pros and cons of different third party solutions, we found that none satisfied all our requirements. Particularly the lack of insight into the underlying technology drove us to the decision to develop our own solution, which we then could deeply integrate into products. That way, it would become the “glue” that enables us to transmit streams between all our different products, locally or across far distances, while maintaining our low latency proposition.
在评估了不同的第三方解决方案的优缺点后&＃xff0c;我们发现没有一个能满足我们所有的需求。 特别是对底层技术缺乏深入的了解&＃xff0c;促使我们决定开发自己的解决方案&＃xff0c;然后将其深入集成到产品中。 这样&＃xff0c;它将成为“粘合剂”&＃xff0c;使我们能够在本地或长距离传输所有不同产品之间的流&＃xff0c;同时保持我们的低延迟观点。

There were a few of possible choices to consider:
有几个可能的选择可以考虑:

• The TCP based approach. Problem for live streaming: Network congestion, too slow packet loss recovery.
• 基于TCP的方式。 直播问题:网络拥塞&＃xff0c;数据包丢失恢复太慢。
• The UDP based Approach. General problem: Packet loss, jitter, packet re-ordering, delay
• 基于UDP的方法。 一般问题:包丢失&＃xff0c;抖动&＃xff0c;包重新排序&＃xff0c;延迟
• Reliable UDP. Adds framing and selective retransmit.
• 可靠UDP。 添加帧和选择性重传。

Having had a history with UDT for data transmission, I remembered its packet loss recovery abilities and just started playing with it. Though not designed for live streaming at all, it kind of worked when using really big buffers. I handed it over to one of our extremely talented networking guys in the embedded software team (thanks, Jean!) and asked him whether he’d be able to make this a low latency live streaming solution. I didn’t hear anything back for quite a while and had almost lost my hope, when he contacted me to tell me he had to rewrite the whole packet retransmission functionality in order to be able to react to packet loss immediately when it happens and that he added an encryption protocol, which he had specified and implemented for other use cases before. Nice &＃x1f603;
曾经使用UDT进行数据传输&＃xff0c;我想起了它的丢包恢复功能&＃xff0c;并开始使用它。 虽然不是为实时流设计的&＃xff0c;但当使用真正大的缓冲区时&＃xff0c;它是有效的。 我把它交给了我们嵌入式软件团队中一个非常有才华的网络人员(谢谢Jean!)&＃xff0c;并问他是否可以把它变成一个低延迟的直播流媒体解决方案。 我很长一段时间没有收到任何回复&＃xff0c;几乎失去了希望&＃xff0c;当他联系我&＃xff0c;告诉我他必须重写整个数据包重传功能&＃xff0c;以便能够在发生数据包丢失时立即做出反应&＃xff0c;他添加了一个加密协议, 他之前已经为其他用例指定并实现了。 好:-)

We started testing sending low latency live streams back and forth between Germany and Montreal and it worked! However, we didn’t get the latency down to a level we had hoped to achieve. The problem we faced turned out to be timing related (as always in media …).
我们开始测试在德国和蒙特利尔之间发送低延迟的实时流&＃xff0c;它工作了! 然而&＃xff0c;我们并没有将延迟降低到我们希望达到的水平。 我们所面临的问题其实与时间有关(游戏邦注:在媒体中总是如此)。

What happened was this:
事情是这样的:

The characteristics of the original stream on the source network got completely changed by the transmission over the public internet. The reasons are delay, jitter, packet loss and its recovery on the dirty network. The signal on the receiver side had completely different characteristics, which led to problems with decoding, as the audio and video decoders didn’t get the packets at the expected times. This can be handled by buffering, but that’s not what you want in low latency setups.
原始流在源网络上的特性完全被公共互联网上的传输所改变。 其原因是恶劣网络存在时延、抖动、丢包及其恢复。 接收端的信号具有完全不同的特征&＃xff0c;这导致解码问题&＃xff0c;音频和视频解码器没有在预期的时间内得到数据包。 这可以通过缓冲来处理&＃xff0c;但在低延迟设置中这不是您想要的。

The solution was to come up with a mechanism that recreates the signal characteristics on the receiver side. That way we were able to dramatically reduce the buffering. This functionality is part of the SRT protocol itself, so once the data comes out of the SRT protocol on the receiver side, the stream characteristics have been properly recovered.
解决方案是想出一种机制&＃xff0c;在接收端重建信号特征。 这样我们就能显著减少缓冲。 这个功能是SRT协议本身的一部分&＃xff0c;所以一旦数据从接收端的SRT协议出来&＃xff0c;流的特征就被正确地恢复了。

The result is a happy decoder:
结果是一个令人愉快的解码器:

We publicly showed SRT (Secure Reliable Transport) the first time at IBC 2013, where we were the only ones to show an HEVC encoded live stream, camera to glass, from a hotel suite outside the exhibition directly onto the show floor, using the network provided by the RAI. Everybody who has been at such a show before knows how bad these networks can get. And the network was bad. So bad that we expected the whole demo to fall apart, having pulled the first trial version of SRT directly from the labs. The excitement was huge, when we realized that the transmission still worked fine!
我们首次在IBC 2013上公开展示了SRT (Secure Reliable Transport)&＃xff0c;在那里我们是唯一一个使用RAI提供的网络&＃xff0c;从展会外的酒店套房直接到展厅展示HEVC编码的直播流&＃xff0c;摄像机到玻璃。 每个看过这种节目的人都知道这些网络有多糟糕。 网络也不好。 如此糟糕&＃xff0c;以至于我们预计整个演示会崩溃&＃xff0c;并直接从实验室取出了SRT的第一个试验版本。 当我们发现变速器还能正常工作时&＃xff0c;我们非常兴奋!

Since then, we added SRT to all our products, enabling us to send high quality, low latency video from and to any endpoint, including our mobile applications. Of course there were improvements to be made and the protocol matured on the way. Until NAB 2017, where we announced that SRT is now Open Source.
从那时起&＃xff0c;我们将SRT添加到我们所有的产品中&＃xff0c;使我们能够从任何端点发送高质量、低延迟的视频&＃xff0c;包括我们的移动应用程序。 当然&＃xff0c;该协议还有待改进&＃xff0c;也在不断成熟。 直到2017年NAB&＃xff0c;我们宣布SRT现在是开源的。

Marc
马克