RIST and SRT overview: what to choose and why

New times place new demands in terms of data transfer speeds and delivery reliability, while the amount of content being transferred keeps growing. When tasked with delivering high-definition video via the public internet, network and content providers inevitably encounter the following problems: 

• delivery is not guaranteed, and the video on the receiving side may have missing frames, be out of sync, or contain artifacts or frozen frames
• many solutions have a high latency and cannot be used for live event broadcasting
• a desire to be able to use a link of any bandwidth, or even several links
• the content needs to be protected against theft
• the implementation needs to be simple, while the protocol must be compatible with other hardware and software.

Many vendors, content providers, network providers, and broadcasters are at a loss: which protocols should they support and implement in their encoders, players, set-top boxes, and playout systems? Meanwhile, low-latency, guaranteed data delivery protocols such as RIST and SRT have gained a lot of popularity lately. But which of them should you choose?

What do RIST and SRT have in common?

Both protocols are designed for low-latency video delivery via public internet networks. SRT was originally developed by Haivision for use in their own encoders and decoders. It was released as an open real-time video delivery protocol in 2017. Note that Haivision is not only the developer of SRT and the founder of the SRT Alliance but also a member of the RIST Forum which is part of the Video Services Forum.

2017 was also the year when the development of RIST started. Many companies used various RIST implementations in their products, but their solutions were not mutually compatible. 

RIST and SRT have the same encryption level and both support high-bitrate streaming and Forward Error Correction (SMPTE 2022-1). Both protocols support pre-shared keys up to 256 bits in length and automatic repeat requests (ARQ), can bypass firewalls, and allow tradeoffs between delivery reliability and latency.

Today, both protocols are implemented as open-source libraries, which helps accelerate and simplify the launch of broadcasting as well as avoid dependency on a specific vendor, as opposed to using proprietary solutions like Zixi.

SRT and RIST are present in many popular solutions and frameworks, such as AWS Media Connect, Nimble Streamer, VLC, gstreamer, ffmpeg, and wireshark (via plugins). The librist and libsrt libraries are available for all three major operating systems: Windows, Linux, and MacOS.

What is the difference between the protocols?

SRT was originally developed by a single company based on UDT (UDP-based Data Transfer Protocol), a well-known and proven file transfer protocol. UDT is much faster than TCP and can be easily configured. Unlike files, however, media data are much larger in volume and very susceptible to losses. SRT shows excellent performance at a low or medium packet loss ratio — say, no more than 10% to 12%. The primary aim of SRT was to replace the legacy RTMP protocol that Amazon stopped supporting, while browsers dropped the support of Flash plugins.

RIST was co-developed by a team of experts from different companies specializing in video content delivery (the Video Service Forum and a group of technical representatives from various media companies that would later form the RIST Forum). RIST is based on the RTP, RTCP, and SMPTE-2022 protocols (with IP transport) as well as several other Internet standards (RFC). RIST was originally developed for transferring video content and incorporated much of the experience gained in developing the earlier open and proprietary streaming protocols. RIST can recover up to 55% of sustained and up to 86% of short-term packet losses.

Even old players, transcoders, media servers, or analyzers can work with RIST on the basic level by accepting RTP, however, they do not support SRT.

The approach to authorization is different with the two protocols. SRT uses only pre-shared keys (PSK), which provides an acceptable level of security but does not suit all broadcasters. RIST also uses PSK but can be supplemented with the SRP (Secure Remote Password) protocol for additional protection. In addition, RIST supports DTLS with certificate-based authorization, which is a fundamental requirement of most broadcasters. 

For firewall bypass, SRT uses the concept of caller/listener handshaking without permanent rule configuration and also has a special rendezvous mode for that purpose. The principle is based on the connection monitoring function in firewalls. RIST, on the other hand, uses RTCP messages for bypassing firewalls.

The methods for lost packet retransmission also differ between the protocols. SRT is not always suitable for narrow-band internet links because it can congest the link with retransmitted packets in case of a high error rate, whereas RIST has the ability to reduce bandwidth consumption for such retransmission. ARQ is implemented in RIST using NACK only, whereas SRT uses both NACK and ACK to acknowledge receipt.

SRT only supports point-to-point mode, while RIST employs the point-to-multipoint approach, including multilink support and a multicast implementation. In contrast to SRT, which is based on an open-source library with a reference implementation from one specific company, RIST is based on open specifications developed with the participation of a group of companies. The librist project has active volunteers who contribute as testers and technical developers.

Why choose SRT?

With SRT, the lost packets are rebroadcast as soon as possible, meaning a higher content quality and lower latency, unless the bandwidth is limited.

Today, SRT has already gained a certain level of market share and spurred an alliance of developer companies that support this protocol and use it in their solutions. SRT is an open-source project that has attracted a considerable community. Currently, the SRT Alliance has more than 450 member companies, including the recently joined AWS, OBS, and Sony.

SRT also works well for transmitting large volumes of data but suffers a sharp decline in efficiency or becomes totally inefficient at loss ratios of 15% and more, which is confirmed by various research studies.

Being still more common today than RIST, SRT is more effective in terms of compatibility with the potential environment. Unlike RIST, SRT is already present in popular solutions such as OBS Studio and Wowza. 

The release of SRT v1.5 was planned for 2020 but has still not happened at the time of writing. In this release, the developers promise to implement bonding, C++11 support, and bi-directional metadata exchange as well as improve bandwidth estimation and multicast support.

I have already discussed SRT in detail in an earlier article.

Why choose RIST?

RIST supports IP multicast broadcasting, which enables considerable traffic and network resource savings. RIST makes it possible to broadcast several streams in parallel (multistream multiplexing), requiring only a single UDP port. Seamless switching without glitching is supported between stream copies transmitted over backup links based on the widely used SMPTE 2022-7 standard. On the receiving side, RIST combines several streams into one common stream (link aggregation/bonding). 

Since RIST is based on RTP, the vast majority of devices that accept the RTP protocol can also work with RIST to some extent (except for the ability to handle packet retransmission and other killer features of RIST).

RIST has the ability to reduce traffic during packet retransmission to achieve stable broadcasting and eliminate traffic overhead by discarding null packets (padding/stuffing). RIST is optimized for transmitting high-bitrate video via RTP header extension, which allows the range of packet numbering to be expanded from 16 bits to 32 bits. RIST is also deemed to have better security because it supports both PSK (Pre-Shared Key) and DTLS certificate-based encryption which is considered more secure and used by the majority of banks. RIST can recover from losses of up to 25% with 100% overhead and up to 50% loss with 200% overhead. During testing at the Virtual NAB trade show in 2020, RIST was demonstrated to recover from an 86% burst loss with a successful delivery of all the packets (Fig. 1).
 

Fig. 1 – Successful recovery of all the packets with a burst loss of 86%

A new Enhanced/Advanced profile is currently in development for the protocol. It can be expected to include improved bandwidth management, adaptive bitrate, lossless compression, optimized management of the created broadcast links, hybrid broadcasting support as implemented in HbbTV and ATSC 3.0, and other things (Fig. 2). The release of the Advanced Profile is already planned for 2021. 

Fig. 2 – RIST Roadmap

Conclusion

Compatibility has always played an essential role in the video industry. To achieve compatibility, various standards were conceived and approved that could bring together different vendors under a common infrastructure where proprietary technology always has the potential to become a project bottleneck.

Producing content in a form that is accessible for all partners, customers, network providers, post-production houses, and viewers is a key requirement for any broadcaster. But as time goes by, broadcasters' demands increase, concerning not only compatibility but also in terms of usability, latency, bandwidth minimization while maintaining the ability to broadcast UHD content, broadcasting over lossy public networks, security, authorization, and ease of configuration and management. In response to these demands, new technologies and protocols are emerging, including the two that are being compared in this article. Both protocols are already widely used: at the time of writing, the SRT Alliance has more than 450 member companies while the RIST Forum has more than 130. However, it is anyone's guess as to who will capture the market in the medium- and long-term. Perhaps a time will come when SRT and RIST will be combined into a single protocol, because, despite the differences, they serve a similar purpose and are close to each other in their functional characteristics.

A comparison of SRT and RIST that summarizes all of the above is provided in the table below.

Here is the comment from one of the main developers of open source RIST library librist – Gijs Peskens – about what he thinks about RIST and SRT comparison:

“I think the biggest reason why I love the RIST protocol is because it's very simple. I would be able to sit down with someone and be able to explain the core simple profile protocol in less than half an hour, less if they have a good knowledge of video flows and networking I guess. From an operation side of things I think the prime reasons we went with RIST are that simple profile supports multicast (something SRT at the time did not, I'm not sure if it does at this moment), and it being backwards compatible with plain RTP receivers.

To dive a bit deeper into the protocol, RIST was designed from the get-go as a protocol for video transport, primarily MPEG-TS, and is based on existing technologies used in video transport/networking like RTP and GRE, and uses Adaptive Retry reQuests to signal packet loss to the sender.

About libRIST, which I help maintain, we just released our first stable release, and are laying the ground work for 0.3 which will feature full duplex communication, certificate based access control and more”.

Try Elecard CodecWorks - live encoder and streamer supporting SRT. RIST support is coming soon.

Request CodecWorks demo

Author

Vitaly Suturikhin

Head of Integration and Technical Support Department at Elecard since 2015. Vitaly has over 15 years of experience in information technology. He is in charge for support of the most important Elecard clients such as MTS, Moscow Metro, Innet, ReadyTV. Vitaly was responsible for IPTV and DVB broadcasting at FIFA Confederations Cup 2017 and FIFA World Cup 2018 in St. Petersburg.

June 29, 2021