Contribution

Video: Enhanced Usage of the RIST Protocol to Address Network Challenges

Posted on by Russell Trafford-Jones

The Reliable Internet Stream Transport (RIST) is an open specification from the Video Services Forum which allows for reliable tansmission of video, audio and other data over lossy links. It does this by retransmitting any lost packets which the receiver hopes to receive before its receive buffer is exhausted. A seemingly simple, but powerful feature of RIST is delivery of multiple links to be bonded together to deliver to a single receiver. In this video, Adi Rozenberg explains the many ways to use this flexible functionality. If you’re new to RIST, check out this SMPTE primer or this intro from AWS.

Adi starts by outlining the basic functionality which allows a sender, using multicast or unicast, to set up multiple links to a destination. Each of these links will be managed by an RTCP channel. This setup allows for a number of strategies to deliver content.

 

 

RIST supports a number of output modes. In the standard mode, packets are passed through without modification. Header conversion can be added, however, which allows the destination IP, UDP port and source IP to be changed. There are also modes determining whether a link carries stream data, just any retransmitted packets or both. In most similar protocols, the default is that a link carries both the stream data and the retransmitted data. Lastly, it’s possible to define that normally a percentage of traffic goes down each path which then adjusts if one or more links go down.

Adi outlines the following systems:

  • Stream transmission over three links with retransmissions sent over any link
  • Dynamic load share with three links carrying 45%, 45% & 10% load respectively. This cuts down on bandwidth compared to the first option which needs 300% of the stream bandwith.
  • Use of three links where the third takes retransmission traffic only.

These systems allow for use cases such as splitting the video bitrate between two or more links, having a low-bandwidth backup link normally carrying 3% traffic but which can burst up to 100% if the main link fails. This would work well for cloud-provided feeds where the main delivery is satellite RF and the IP delivery is dependent on the cloud and therefore the cost is related to egress charges or conversely if the RF link is paid for such as a 4G cellular link, the 3% would lie on that and DSL would handle the main delivery.

Watch now!
Speaker

Adi Rozenberg Adi Rozenberg
CTO & Co Founder
VideoFlow

Video: CMAF Live Media Ingest Protocol Masterclass

Posted on by Russell Trafford-Jones

We’ve heard before on The Broadcast Knowledge about CMAF’s success at bringing down the latency for live dreaming to around 3 seconds. CMAF is standards based and works with Apple devices, Android, Windows and much more. And while that’s gaining traction for delivery to the home, many are asking whether it could be a replacement technology for contribution into the cloud.

Rufael Mekuria from Unified Streaming has been working on bringing CMAF to encoders and packagers. All the work in the DASH Industry forum has centred around to key points in the streamin architecture. The first is on the output of the encoder to the input of the packager, the second between the packager and the origin. This is work that’s been ongoing for over a year and a half, so let’s pause to ask why we need a new protocol for ingest.

 

 

RTMP and Smooth streaming have not been deprecated but they have not been specified to carry the latest codecs and while people have been trying to find alternatives, they have started to use fragmented MP4 and CMAF-style technologies for contribution in their own, non-interoperable ways. Push-based DASH and HLS are common but in need of standardisation and in the same work, support for timed metadata such as splice information for ads could be addressed.

The result of the work is a method of using a separate TCP connection for each essence track; there is a POST command for each subtitles stream, metadata, video etc. This can be done with fixed length POST, but is better achieved with chunked tranfer encoding.

Rufael next shows us an exmaple of a CMAF track. Based on the ISO BMFF standard, CMAF specifies which ‘boxes’ can be used. The CMAF specification provides for optional boxes which would be used in the CMAF fragements. Time is important so is carried in ‘Live basemedia decodetime’ which is a unix-style time stamp that can be inserted into both the fragment and the CMAF header.

With all media being sent separately, the standard provides a way to define groups of essences both implicitly and explicity. Redundancy and hot failover have been provided for with multiple sources ingesting to multiple origins using the timestamp synchronisation, identical fragments can be detected.

The additional timed metadata track is based on the ISO BMFFF standard and can be fragmented just like other media. This work has extended the standard to allow the carrying of the DASH EventMessageBox in the time metadata track in order to reuse existing specifications like id3 and SCTE 214 for carrying SCTE 35 messages.

Rufael finishes by explaining how SCTE messages are inserted with reference to IDR frames and outlines how the DASH/HLS ingest interface between the packager and origin server works as well as showing a demo.

Watch now!
Speaker

Rufael Mekuria Rufael Mekuria
Head of Research & Standardisation,
Unifed Streaming

Video: Creating Interoperable Hybrid Workflows with RIST

Posted on by Russell Trafford-Jones

TV isn’t made in one place anymore. Throughout media and entertainment, workflows increasingly involve many third parties and being in the cloud. Content may be king, but getting it from place to place is foundational in our ability to do great work. RIST is a protocol that is able to move video very reliably and flexibly between buildings, into, out of and through the cloud. Leveraging its flexibility, there are many ways to use it. This video helps review where RIST is up to in its development and understand the many ways in which it can be used to solve your workflow problems.

Starting the RIST overview is Ciro Noronha, chair of the RIST Forum. Whilst we have delved in to the detail here before in talks like this from SMPTE and this talk also from Ciro, this is a good refresher on the main points that RIST is published in three parts, known as profiles. First was the Simple Profile which defined the basics, those being that it’s based on RTP and uses an ARQ technology to dynamically request any missing packets in a timely way which doesn’t trip the stream up if there are problems. The Main Profile was published second which includes encryption and authentication. Lastly is the Advanced Profile which will be released later this year.

 

 

Ciro outlines the importance of the Simple Profile. That it guarantees compatibility with RTP-only decoders, albeit without error correction. When you can use the error correction, you’ll benefit from correction even when 50% of the traffic is being lost unlike similar protocols such as SRT. Another useful feature for many is multi-link support allowing you to use RIST over bonded LTE modems as well as using SMPTE ST 2022-7

The Main Profile brings with it support for tunnelling meaning you can set up one connection between two locations and put multiple streams of data through. This is great for simplifying data connectivity because only one port needs to be opened in order to deliver many streams and it doesn’t matter in which direction you establish the tunnel. Once established, the tunnel is bi-directional. The tunnel provides the ability to carry general data such as control data or miscellaneous IT.

Encryption made its debut with the publishing of the Main Profile. RIST can use DTLS which is a version of the famous TLS security used in web sites that runs on UDP rather than TCP. The big advantage of using this is that it brings authentication as well as encryption. This ensures that the endpoint is allowed to receive your stream and is based on the strong encryption we are familiar with and which has been tested and hardened over the years. Certificate distribution can be difficult and disproportionate to the needs of the workflow, so RIST also allows encryption using pre-shared keys.

Handing over now to David Griggs and Tim Baldwin, we discuss the use cases which are enabled by RIST which is already found in encoders, decoders and gateways which are on the market. One use case which is on the rise is satellite replacement. There are many companies that have been using satellite for years and for whom the lack of operational agility hasn’t been a problem. In fact, they’ve also been able to make a business model work for occasional use even though, in a pure sense, satellite isn’t perfectly suited to occasional use satellites. However, with the ability to use C-band closing in many parts of the world, companies have been forced to look elsewhere for their links and RIST is one solution that works well.

David runs through a number of others including primary and secondary distribution, links aggregation, premium sports syndication with the handoff between the host broadcaster and the multiple rights-holding broadcasters being in the cloud and also a workflow for OTT where RIST is used for ingest.

RIST is available as an open source library called libRIST which can be downloaded from videolan and is documented in open specifications TR-06-1 and TR-06-2. LibRIST can be found in gstreamer, Upipe, VLC, Wireshark and FFmpeg.

The video finishes with questions about how RIST compares with SRT. RTMP, CMAF and WebRTC.

Watch now!
Speakers

Tim Baldwin Tim Baldwin
Head of Product,
Zixi
David Griggs David Griggs
Senior Product Manager, Distribution Platforms
Disney Streaming Services
Ciro Noronha Ciro Noronha
President, RIST Forum
Executive Vice President of Engineering, Cobalt Digital

Video: Tweaking Error Correction Protocol Performance: A libRIST Deep Dive

Posted on by Russell Trafford-Jones

There’s a false assumption that if you send video with these new error-correcting protocols like RIST or SRT that you just need to send the stream, it’ll get healed and everything will be good. But often people don’t consider what actually happens when things go wrong. To heal the stream, more data needs to be sent. Do you have enough headroom to cope with these resends? And what happens if part of your circuit becomes temporarily saturated, how will the feed cope? The reality is that it could kill it permanently due to re-request storms.

In this video from VidTrans21, Sergio Ammirata from SipRadius talks about how the error correcting protocol within RIST works and how it’s been improved to cope even better in a crisis. Joined by Adi Rozenberg they remind us of the key points of RIST and the libRIST. As a reminder, RIST is one of many protocols which allows the receiver to let the sender know which packets its missed and for them to be resent. For a proper overview of RIST and SRT, have a look at this talk explaining RIST and SRT or the multitude of talks here on The Broadcast Knowledge on RIST or SRT. Today’s video is not so much about why people use RIST, but how to make it performant with difficult circuits.

 
libRIST is an open-source, free, library which implements the RIST specification. The aim of libRIST is to allow companies to easily implement RIST within their own commercial and free programmes. Sergio points out that it’s an active project with over 675 commits in the last year bringing RIST to many platforms including ARM, AWS, Darwin, iOS, windows etc. and is now on version 0.2.0, plus is soon to be in VLC 4.0 and FFmpeg 4.3.

To understand why getting error correction is important, we can look at the effects of a simplistic implementation of the negative acknowledgement error recovery method. When the receiver doesn’t receive a packet it sends back a request for a resend of that packet. The sender will send that and, hopefully, it will be received. Let’s imagine, though, that you’re in a data centre sending to someone on a 100Mbps leased line. If the incoming bitrate of your receiver’s internet connection started getting close to 100Mbps due to the aggregate traffic coming into the site, the receiver may start missing out on occasional packets leading it to ask for more packets from the sender. The sender’s bitrate then increases which reduces the margin available in the incoming circuit resulting in more lost packets. This cycle continues until the line is saturated. It’s important to remember that saturating an incoming link doesn’t mean traffic can’t get out. It’s quite possible there are hundreds of megabits available outgoing so there’s plenty of bandwidth to shout for more and more re-requests. The sender is quite happy to send these re-requests as it’s on a 10Gbe link and has plenty of headroom left. Only by stopping the receiver would you be able to break this positive-feedback loop.

Now, all protocols deliver some form of control over what’s re-requested to try to manage difficult situations. Sergio agrees that other implementations of RIST work well in normal situations with less than 10% packet loss, for example. But where bursts of packet loss exceed 20% or the circuit headroom dips below 20%, Sergio says implementations tend to struggle.

As a lead-up up to the recent improvements made in congestion management, Sergio outlines how libRIST uses internal QOS to maintain a bandwidth cap. It will also monitor the RTT every tenth of a second to help spread retries over time. By checking how the RTT is changing in these extreme conditions, libRIST is able to throw away redundant re-requests leaving more bandwidth for useful requests. The fact that the sender is doing this work means that even if the receiver is on an older version of libRIST or on another implementation, the link can still benefit from the checking the libRIST 0.2.0 is doing. The upshot of all this work is that no longer can libRIST deal with 50% packet loss, it can now deliver an unblemished stream up to just shy of 70% packet loss.

Watch now!
Speaker

Sergio Ammirata Sergio Ammirata Ph.D.
Chief Scientist,
SipRadius LLC
Adi Rozenberg Adi Rozenberg
CTO & Co-founder,
VideoFlow