Video: RIST: Enabling Remote Work with Reliable Live Video Over Unmanaged Networks

Last week’s article on RIST, here on The Broadcast Knowledge, stirred up some interest about whether we view RIST as being against SRT & Zixi, or whether it’s an evolution thereof. Whilst the talk covered the use of RIST and the reasons one company chose to use it, this talk explains what RIST achieves in terms of features showing that it has a ‘simple’ and ‘main’ profile which bring different features to the table.

Rick Ackermans is the chair of the RIST Activity Group which is the group that develops the specifications. Rick explains some of the reasons motivating people to look at the internet and other unmanaged networks to move their video. The traditional circuit-based contribution and distribution infrastructure on which broadcasting relied has high fixed costs. Whilst this can be fully justifiable for transmitter links, though still expensive, for other ad-hoc circuits you are paying all the time for something which is only occasionally used, satellite space in the C-band is reducing squeezing people out. And, of course, remote working is much in the spotlight so technologies like RIST which don’t have a high latency (unlike HLS) are in demand.

RIST manages to solve many of the problems with using the internet such as protecting your content from theft and from packet loss. It’s a joint effort between many companies including Zixi and Haivision. The aim is to create choice in the market by removing vendor bias and control. Vendors are more likely to implement an open specification than one which has ties to another vendor so this should open up the market creating more demand for this type of solution.

In the next section, we see how RIST as a group is organised and who it fits in to the Video Services Forum, VSF. We then look at the profiles available in RIST. A full implementation aims at being a 3-layer onion with the ‘Simple Profile’ in the middle. This has basic network resilience and interoperability. On top of that, the ‘Main Profile’ is built which adds encryption, authentication and other features. The future sees an ‘Enhanced Profile’ which may bring with it channel management.

Rick then dives down into each of these profiles to uncover the details of what’s there and explain the publication status. The simple profile allows full RTP interoperability for use as a standard sender, but also adds packet recovery plus seamless switching. The Main profile introduces the use of GRE tunnels where a single connection is setup between two devices. Like a cable, multiple signals can then be sent down the cable together. From an IT perspective this makes life so much easier as the number of streams is totally transparent to the network so firewall configuration, for example, is made all the simpler. However it also means that by just running encryption on the tunnel, everything is encrypted with no further complexity. Encryption works better on higher bitrate streams so, again, running on the aggregate has a benefit than on each stream individually. Rick talks about the encryption modes with DTLS and Pre-shared Key being available as well as the all important, but often neglected, step of authenticating – ensuring you are sending to the endpoint you expected to be sending to.

The last part of the talk covers interoperability, including a comparison between RIST and SRT. Whilst there are many similarities, Rick claims RIST can cope with higher percentages of packet loss. He also says that 2022-7 doesn’t work with SRT, though The Broadcast Knowledge is aware of interoperable implementations which do allow 2022-7 to work even through SRT. The climax of this section is explaining the setup of the RIST NAB demo, a multi-vendor, international demo which proved the reliability claims. Rick finishes by examining some case studies and with a Q&A.

Watch now!
Speakers

Merrick Ackermans Rick Ackermans
MVA Broadcast Consulting
RIST Activity Group Chair

Video: SRT – The Simple Solution for Your Remote and At-Home Workforce

SRT allows unreliable networks like the Internet to be used for reliable, encrypted video contribution. Created by Haivision and now an Open Source technology with an IETF draft spec, the alliance of SRT users continues to grow as the technology continues to develop and add features. Haivision are members of RIST which Kieran Kunhya spoke about in yesterday’s article.

Being open-source, SRT is widely deployed in across hundreds of manufacturers so there is a lot of choice, although Haivision do focus on their products in this video. The important part is in how the protocol works to keep the data intact which is dealt with in the second segment from Haivision’s Selwyn Jans. Lastly, we hear of some examples of real-world use cases to whet the appetite and start the thought process about how SRT could benefit you.

The fundamental aspect of SRT, as Selwyn explains, is that the packets are counted in at the remote end and if one packet is missing, it’s re-requested from the source. Whilst this is how normal file transfers work, using TCP, this has been optimised to ensure real-time media isn’t unduly delayed. TCP would acknowledge every single packet and the sender should take note when a packet acknowledgement doesn’t arrive. SRT is more efficient whereby acknowledgements are minimised, only re-requests which keeps overheads down. A buffer is set up in the destination so that there is still data available while we’re waiting for these packets to be resent. Depending on the network quality, we may need to have enough buffer to deal with several re-requests for the sane packet.

How SRT Works

Selwyn expands upon this re-request mechanism and looks the way SRT can be sent, or ‘pushed’, as well as working in as a ‘listener’ so that the sender waits to be contacted. before it starts sending any data. You can choose the best one to use to fit around your firewalls. Where there is a NAT firewall, SRT can always be sent out but receiving requests would need firewall modification. One of the benefits of SRT is its ability to be deployed anywhere, including in a home, quickly and easily so firewall changes would not be welcome. For a more in-depth description of SRT, check out this talk from SF Video Technology.

The last section features Corey Behnke from streaming company Live X talking about where they have been using SRT. Replacing satellite is one important use of SRT since in many places, there is sufficient bandwidth available to stream over the internet. Before technologies such as SRT, this was likely to lead to breakups on air, so satellite was the clear winner. Now, there’s money to be saved by not buying satellite space. Could ingress and egress is also a very important workflow for SRT, and similar protocols. The panelists explain how this works using as an example the Haivision Media Gateway, though other products such as Techex and Videoflow.

Watch now!
Speakers

Marcus Schioler Marcus Schioler
Vice President, Product Marketing
Haivision
Selwyn Jans Selwyn Jans
Technical Video Engineer,
Haivision
Corey Behnke Corey Behnke
Producer & Co-Founder,
Live X

Video: RIST and Open Broadcast Systems

RIST is a streaming protocol which allows lossy networks such as the internet to be used for critical streaming applications. Called Reliable Internet Stream Transport, it uses ARQ (Automatic Repeat reQuest) retransmission technology to request any data that is lost by the network, creating reliable paths for video contribution.

In this presentation, Kieran Kunhya from Open Broadcast Systems explains why his company has chosen RIST protocol for their software-based encoders and decoders. Their initial solution for news, sports and linear channels contribution over public internet were based on FEC (Forward Error Correction), a technique used for controlling errors in transmission by sending data in a redundant way using error-correcting code. However, FEC couldn’t cope with large burst losses, there was limited interoperability and the implementation was complex. Protecting the stream by sending the same feed over multiple paths and/or sending a delayed version of the stream on the same path, had a heavy bandwidth penalty. This prompted them, instead, to implement an ARQ technique based on RFC 4585 (Extended RTP Profile for Real-time Transport Control Protocol-Based Feedback), which gave them functionality quite similar to the basic RIST functionality.

Key to the discussion, Kieran explains why they decided not to adopt the SRT protocol. As SRT is based file transfer protocol, it’s difficult or impossible to add features like bonding, multi-network and multi-point support which were available in RIST from day one. Moreover, RIST has a large IETF heritage from other industries and is vendor-independent. In Kieran’s opinion, SRT will become a prosumer solution (similar to RTMP, now, for streaming) and RIST will be the professional solution (analogous to MPEG-2 Transport Streams).

Different applications for the RIST protocol are discussed, including 24/7 linear channels for satellite uplink from playout, interactive (two-way) talking heads for news, high bitrate live events and reverse vision lines for monitoring purposes. Also, there is a big potential for using RIST in cloud solutions for live broadcast production workflows. Kieran hopes that more broadcasters will start using spin-up and spin-down cloud workflows, which will help save space and money on infrastructure.

What’s interesting, Open Broadcast Solutions are not currently interested in RIST Main Profile (the main advantages of this profile are support for encryption, authentication and in-band data). Kieran explains that to control devices in remote locations you need some kind of off-the-shelf VPN anyway. These systems provide encryption and NAT port traversal, so the problem is solved at a different layer in the OSI model and this gives customers more control over the type of encryption they want.

Watch now!

Speaker

Kieran Kunhya Kieran Kunhya
Founder and CEO,
Open Broadcast Systems

Video: Specification of Live Media Ingest

“Standardisation is more than just a player format”. There’s so much to a streaming service than the video, a whole ecosystem needs to work together. In this talk from Comcast’s Mile High Video 2019, we see how different parts of the ecosystem are being standardised for live ingest.

RTMP and Smooth streaming are being phased out – without proper support for HEVC, VVC, HDR etc. they are losing relevance as well as, in the case of RTMP, support from the format itself. Indeed it’s clear that fragmented MP4 (fMP4) and CMAF are taking hold in their place so it makes sense for a new ingest standard to coalesce around these formats.

Rufael Mekuria from Unified streaming explains this effort to create a spec around live media ingest that is happening as part of MPEG DASH-IF. The work itself started at the end of 2017 with the aim of publishing summer 2019 supporting CMAF and DASH/HLS interfaces.

Rufael explains CMAF ingest used HTTP post to move each media stream to the origin packager. The tracks are separated into video, audio, timed text, subtitle and timed metadata. They are all transferred on separate tracks and is compatible with future codecs. He also covers security and timed text before covering DASH/HLS ingest which can also contain CMAF because HLS contains the capability to contain CMAF.

Reference software is available along with the <a href=”http://”https://dashif-documents.azurewebsites.net/Ingest/master/DASH-IF-Ingest.pdf” rel=”noopener noreferrer” target=”_blank”>specification.

Watch now!
Speaker

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