As more broadcasters are looking to use the internet and the Cloud to contribute and distribute live video, transport protocols such as RIST and SRT are becoming increasingly important. However, at the same time, there is growing confusion surrounding them, with many believing the different protocols to be essentially the same. This makes it difficult for broadcasters to determine what they need and often leads them to making the wrong choice. So, what is the difference and when and why does it matter?
   

RIST and SRT

Both Secure Reliable Transport (SRT) and Reliable Internet Stream Transport (RIST) have been developed to enable live low-latency video contribution over the public internet.

SRT was originally developed and pioneered by Haivision for use in its own encoder/decoder products. In 2017 it became an open source protocol and technology stack for the delivery of live video. RIST development started in 2017 in the context of the Video Services Forum at the request of the broadcast industry. The industry felt the need for a unified and interoperable protocol that was better suited for the professional industry. The primary driver for RIST development was the fact that there were multiple solutions in the market that worked well but did not interoperate.

Fundamental Differences

SRT was developed by a single company based on an old file transfer protocol, UDT. Its main advertised goal was, and still is, to replace RTMP. RIST, on the other hand was developed by a group of experts from multiple competing companies, all with a strong background and extensive experience in solutions for video delivery. One of the first actions of the RIST Activity Group was to evaluate SRT – but, after this vetting, the group concluded that SRT was not adequate to ensure the high quality needed by the broadcast industry. RIST, on the other hand, is based on a well known suite of streaming protocols already adopted by the broadcast industries: RTP and SMPTE-2022 (Transport Stream over IP), as well as a number of relevant RFCs (internet standards). The result is that RIST is simpler to implement and is much better suited for performance and transfer of high-quality video.

RIST implementations are fully interoperable. Unlike SRT and proprietary solutions, RIST is totally vendor-agnostic. Technically speaking, it is a set of guidelines based around other well-known standards, detailing how to apply them in a broadcast setting. This means that vendors can still be innovative and differentiate their solutions when they implement RIST whilst safe in the knowledge that it will work with other solutions, no matter what technology those are using.

The other fundamental difference comes down to security. There are two aspects to security: encryption and authentication. RIST and SRT offer the same level of encryption, but have different approaches to authentication. SRT only uses pre-shared keys, which gives some level of security but not the level required by most broadcasters streaming high value content. RIST offers a pre-shared key mode, which can be augmented with the Secure Remote Password protocol for additional protection. RIST also offers a DTLS mode, with certificate-based authentication – this is the same technology today used by banks and other secure web sites. It ensures that only the people entitled to view your content can access it, a fundamental necessity for the majority of broadcasters.

Other Key Comparisons

There are a number of other key differences between the two protocols. RIST enables point-to-multipoint and IP multicast, making it easy for broadcasters to efficiently deliver transmissions to multiple places using the same link. RIST also supports multi-link operation, both in bonding mode and in seamless switching mode. Bonding allows the user to combine multiple links in parallel to deliver the content. Seamless switching allows the user to send two or more simultaneous copies of the stream over redundant links, so that if a link goes down, there is no hit to the content. In all cases, the RIST receiver combines the multiple flows back into one stream, removing the duplicates as needed. The ability to use redundant links is crucial for broadcasters who require an extra level of reliability. These features are missing from the production SRT 1.4, but a subset is planned for a future release.

The way in which error recovery is handled is also different. SRT tries to optimise and reduce the recovery time by retransmitting lost packets as fast as possible. In bandwidth-constrained links, this can cause further packet losses, and the link will basically grind to a halt. RIST, on the other hand, is capable of optionally throttling retransmissions, so this instability is avoided.  This allows RIST implementations to work well in the more challenging environments where SRT fails.

RIST or SRT?

SRT is often seen as the front runner in video transport because it came to market first and has a large membership. However, it is primarily targeted at prosumer video delivery, aiming to replace the ageing RTMP protocol. In that segment, it does a great job of delivering live video with reasonable quality and security that is good enough. For broadcast, it simply does not have what it takes to give broadcasters the confidence to switch to IP workflows over the internet for their valuable content. RIST was built and designed for broadcasters by experts in the broadcast industry.

As broadcasters continue to look for new and cost-efficient ways to contribute live video, there will be a growing demand for unmanaged IP. RIST is currently the best way broadcasters can ensure that video content is delivered reliably and securely over the Internet.