The broadcast industry has witnessed in the past quarters a rapid adoption of two new technologies, both in the realm of point-to-point distribution of video over the public Internet. NAB 2019 was a good illustration, with lots of stands in the South Upper hall adopting the “SRT alliance” badge. SRT was initially developed by Haivision and is now open-sourced. RIST is a newer standard but is supported by major industry players such as Zixi, VideoFlow and Haivision.

Transmitting video streams over the Internet is not a new idea. In the late 2000s I happened to be the main author of the “multicat” open-source project, better known as the VideoLAN project. This project features a couple of programs (aggregartp and reordertp) allowing point-to-point delivery of an RTP stream with packet retransmission and link aggregation. At the same time several protocols based on TCP coexisted to distribute content to the end user: HTTP progressive download or RTMP. TCP looks like an obvious choice to ensure the reliability of the transmission, as it features built-in packet reordering and packet retransmission.

This is not acceptable in a professional environment, where fast recovery is a must. UDP allows for a better control of the algorithm, which improves the predictability of its behaviour. That is why I chose UDP/RTP for multicat ten years ago, as well as other subsequent proprietary or open implementations.

In the 2010s, two companies developed proprietary solutions for point-to-point delivery over the Internet : VideoFlow and Zixi. They modelled their price list over the prices for satellite contribution: per transferred MB. As a result, you pay for your own bandwidth. The comparison with satellite costs is however very favorable, and they were very successful.

Additionally, Zixi released its software in the form of an application, installable on Windows and Linux operating systems, making it very easy for both customers and manufacturers to integrate it. The incredible success of these solutions awakened other players such as Haivision, who began work on its SRT solution. As it arrived late in a market already saturated by Zixi and VideoFlow, Haivision decided to open source its solution. But with at least three solutions in the market (smaller companies have also developed their own solutions: our company EasyTools has been selling its transmit function based on multicat for years), interoperability quickly became a concern. That is why all these companies created the RIST forum and developed this new protocol.

It is hard to say which of SRT and RIST will prevail. Both protocols are similar: They are based on UDP, and use receiver feedback to retransmit lost packets. But they also have their advantages and drawbacks, summed up in the following table:

SRT supports encryption and multiple connection modes for the receiver: “caller” (where the receiver calls the sender), “listener” (where the receiver waits for incoming packets from the sender) and “rendezvous” (both parties try to contact the other). This implies that SRT only requires a public IP address (or a port forwarding) on one end. RIST on the contrary requires a public IP address on both sides and doesn’t support encryption, consequently RIST will probably be most useful in combination with a VPN software such as “tinc”.

SRT has an additional feature, multiplexing, which allows for several SRT connections on the same UDP port. Bonding is only supported in RIST, with two possible modes: split (each route carries different packets) or duplicate (redundant transmission).

I personally know lots of broadcasters who are looking into SRT or RIST as a cost-effective way to deliver their mezzanine streams to remote network operators or service providers, in spite of expensive private fibre optics or satellite links. But this is only the beginning: Winter is coming.

Cloud platforms provide easy and affordable computing capabilities, which are now widely used in many industries, including the web. But it is still relatively marginal in the broadcast industry, with a scope restricted to non-video related tasks (cloud-based traffic systems for instance) or Internet distribution (AWS Elemental MediaLive and MediaPackage being prime examples). But the advent of reliable transport protocol will allow to move traditional broadcast streams to the cloud for processing, and get them back for traditional distribution.

Most cloud software provider will support either SRT or RIST or both, so that broadcasters only need to invest in “gateways”, moving data to or from cloud servers, with their own SRT or RIST implementation. SRT and RIST may also be used to transfer data between cloud servers, as multicast is not common in these environments, and cloud providers won’t warranty 100% reliability with regards to packet losses and reordering.

Want more information? SRT source code can be downloaded from GitHub. For RIST you can use VLC, gstreamer or Upipe.

Want a product? EasyTools supports both SRT and RIST since version 10.1, and can act as a gateway between them.