{"id":2064,"date":"2019-06-10T15:50:21","date_gmt":"2019-06-10T07:50:21","guid":{"rendered":"http:\/\/myblog.emhct.net.cn\/?p=2064"},"modified":"2019-06-10T15:50:21","modified_gmt":"2019-06-10T07:50:21","slug":"why-we-created-srt-and-the-difference-between-srt-and-udt","status":"publish","type":"post","link":"http:\/\/myblog.emhct.net.cn\/index.php\/archives\/2064","title":{"rendered":"Why We Created SRT and the Difference Between SRT and UDT"},"content":{"rendered":"\n
Article Form :
https:\/\/www.haivision.com\/blog\/broadcast-video\/created-srt-difference-srt-udt\/<\/a> <\/h5>\n\n\n\n

Editor\u2019s Note: This post originally appeared on the GitHub Wiki for SRT<\/a>. It has been slightly modified for formatting. <\/em><\/p><\/h5><\/p>\n\n\n\n

Some people have asked us why we\u2019re using the UDT<\/a> library within our SRT protocol<\/a>. Actually, some people claimed that SRT<\/a> 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\u2019ll get into the details, but will start with a little bit of history.<\/p>\n\n\n\n

Haivision has always been known for lowest latency<\/a> video transmission across IP based networks \u2014 typically MPEG-TS unicast or multicast streams over the UDP protocol<\/a>. This solution is perfect for protected networks and if packet loss<\/a>became a problem, enabling forward error correction<\/a> (FEC) fixed it. At some point we were getting questioned as to whether it would be possible to achieve the same latency between customer sites in different locations, between different cities, countries or even continents.<\/p>\n\n\n\n

Of course it\u2019s possible with satellite links or dedicated MPLS<\/a> networks, but those are quite expensive solutions, so people wanted to use their public internet connectivity instead. While it\u2019s possible to go with FEC<\/a> in some cases, that\u2019s not a reliable solution, as the amount of recoverable packet loss<\/a> is limited, unless you accept a significant amount of bandwidth<\/a> overhead.<\/p>\n\n\n\n

After evaluating the pros and cons of different third party solutions, we found that none satisfied all our requirements. The lack of insight into the underlying technology drove us to the the decision to develop our own solution, which we then could deeply integrate into products. That way, it would become the \u201cglue\u201d that enables us to transmit streams between all our different products, locally or across far distances, while maintaining our low latency<\/a> proposition.<\/p>\n\n\n\n

There were a few of possible choices to consider:<\/p>\n\n\n\n