-->
Save your seat for Streaming Media NYC this May. Register Now!
  • September 23, 2020
  • By Kieran Kunhya Founder and Managing Director, Open Broadcast Systems; Board of Directors, RIST Forum
  • Blog

RIST: Video Transport for Content that Matters

Article Featured Image

The video industry has become more and more crowded over recent years. While video viewing is undoubtedly rising, even more so due to the global pandemic, there are more services launching than ever before. Unsurprisingly video providers are increasingly looking to contribute and distribute video as quickly and cost effectively as possible in order to remain competitive. That, coupled with the sudden need for much more remote media workflows, is likely to drive a surge in IP adoption.

Video transport protocols were developed to enable video providers to contribute and distribute video over standard internet connections. This makes it much more accessible, especially for live contribution from the field, as well as driving costs down as it negates the need for a private IP connection.

There are two main protocols fulfilling this role: Secure Reliable Transport (SRT) and Reliable Internet Stream Transport (RIST). They are both setting out to do the same thing so why do we need two different protocols? In this article, I will attempt to explain the key differences. 

Inception

As the older protocol, SRT is often considered the forerunner. Originally developed by Haivision for use with their own encoder and decoder products, the libsrt code was open sourced in 2017.

SRT played an important role in educating the industry in the need for different protocols for contribution as opposed to protocols designed for distribution for end users. However, broadcasters and other content providers needed a specialist protocol designed specifically to handle high-value video content where reliability and interoperability was paramount. On their request, in particular from key players such as ESPN, this led to the development of RIST, which began in 2017. 

The Underlying Protocol 

The way the two protocols are built differs somewhat. SRT is based on the UDT file transfer protocol, which is designed for transferring files over high speed networks. It can transfer bulk data and has mechanisms to control reliability and congestion. UDT is much faster than Transmission Control Protocol (TCP) and is also highly configurable. In reality it is designed for file transfer, as opposed to for media, which is much more data hungry and susceptible to any loss of quality. That said, SRT has good performance at low/moderate rates of packet loss, around 10-12%.

RIST is based natively on well understood protocols such as RTP and RTCP, widely used in many industries. Because it was being built specifically to enable broadcast-grade video, it was important to use protocols that were designed for video. Of course, RIST also had the benefit of learning from what went before based on the expertise of many manufacturers who had proprietary protocols. In fact as part of the RIST technology evaluation process, SRT was evaluated and found not adequate enough for the needs of the industry. So, when broadcasters were asking for something for professional grade video, the experts developing the protocol could see the downside of tweaking a file transfer protocol for high quality, premium video. As a result RIST has high performance and is able to correct up to 55% continuous packet loss and even up to 85% burst loss (see slide 32 in this presentation).

Encryption

Naturally encryption is something both protocols include, but the main difference between the two protocols is the type of encryption being used.

SRT uses Pre-shared key (PSK) encryption. It uses a string of 64 hexadecimal digits to generate unique encryption keys, which are constantly changed. PSK is simple to implement however it has its limitations. It was really designed for small networks that do not require huge amounts of security. However, once one user is compromised, all users can be hacked, so it has its limitations for providers transporting high value video content.

RIST also offers PSK with key rotation, meaning that the key is automatically and continually changed to enhance security. This is needed for one-to-many operation. However, the main method of authentication within RIST is Datagram Transport Layer Security (DTLS). DTLS is certificate-based, encrypts the video stream, and is designed to protect data privacy and prevent eavesdropping and tampering. DTLS is much more secure than PSK, and is even the authentication method used by most banks. This is important for high-value content. 

Support for Multiple ISPs

One of the most important methods for reliable video transmission is using multiple ISPs, a process called hitless switching or SMPTE 2022-7. This is critically important for the transport of high-value content and allows for resilience between issues on each ISP. Retransmissions are also sent on both ISPs to improve the reliability of the stream. A RIST receiver combines both streams to produce a single stream, removing duplicates as needed.

In particular we can look at this example of a 10-month long stream between London and New York using two ISPs. At a given point during these ten months each ISP had packet loss or other outages, but all packets were successfully recovered:

 

Point-to-Multipoint

With broadcast video, often there is a need for point-to-multipoint feeds. Both protocols are capable of enabling point-to-multipoint, however the way in which this is done is different.

SRT handles this by creating multiple point-to-point sessions. This is the only option for a network that doesn’t support multicast. Essentially this means transmitting multiple copies of the stream. This of course has a knock-on effect on not only bandwidth but also resources, as there is likely only a finite amount of streams that a given sender can handle. 

For RIST, point-to-multipoint is natively supported, so the user receives retransmission requests and resends missing packets, rather than having to create multiple sessions. RIST also supports multicast, which is the most efficient way of doing one-to-many transmissions on a private network.

Tunnels

RIST’s use of tunnels allows for bidirectional transport of non-video traffic over the link. This allows for devices to be controlled remotely, easing configuration. 

Bandwidth Considerations

Bandwidth is an important consideration when broadcasting over the public internet. The quality and stability of internet bandwidth varies greatly, and it is vital that it doesn’t have a negative impact on the video being consumed by viewers. Under heavy packet loss, SRT floods the link with retransmission requests. RIST uses retransmission bandwidth throttling which ensures the link keeps going and that it retains as much quality as possible even when bandwidth is limited. Ultimately this ensures minimal service impact during link breakdown. 

With video providers looking to fully maximise efficiencies, it is also key to be able to deliver video with as minimal bandwidth as possible. RIST enables null packet deletion for transport streams, which frees up about 5% of bandwidth that can be used for other purposes. 

While RIST and SRT are both designed to enable live video delivery over the public internet, RIST has been specifically designed for delivery of professional-grade video. There are many cases where SRT does a good enough job, but for broadcasters and content providers with high quality premium content that needs to be reliably delivered to audiences, RIST is needed for the content that matters.

[Editor's Note: This is a contributed byline from Open Broadcast Systems. Streaming Media accepts contributed bylines based solely on their value to our readers.]

Streaming Covers
Free
for qualified subscribers
Subscribe Now Current Issue Past Issues
Related Articles

RIST and CMAF Will Emerge as Powerhouses in 2020

Zixi Will Release a RIST-Compliant Version in Time for NAB

Zixi announced its first commercial product that supports the RIST emerging standard is only two months away. Look for it at NAB.

Companies and Suppliers Mentioned