Increasingly it seems possible to get the internet from anywhere. That’s not strictly true, of course, but the options for getting the internet to a certain place are expanding by the year. Soon 5G will offer new ways of more reliably getting internet access, satellite internet is seeing more deployments and ISP infrastructure continues to expand. So given the internet touches many of the places that broadcasters want to be, why don’t they use it for video and audio connectivity instead of dedicated lines?
Historically the answer to ‘why not use the internet’ has been ‘it’s not reliable enough’. With packet loss inevitable, it just hasn’t been practical to get video over the internet. A decade ago, there were actually programmes being made over IP links with healthy amounts of FEC being applied. FEC is great for coping with certain types of packet loss. In fact, you can choose how FEC is applied so that it covers you for the type of errors you expect. For some connections frequent, single-packet loss is expected, for others, occasional losses of several consecutive packets. Depending on how you configure. your FEC you can set your self up to be protected from one or the other. The problem is that FEC runs out at some point when packet loss becomes too high and even quicker when you suffer the ‘wrong type’ of packet loss.
ARQ (Automatic Repeat reQuest) is a foundational technology that, when the circuit is good, requires no extra bitrate from the sender, unlike FEC, which is a static 5, 10 or even 25% of extra data. However, when packet loss occurs, it kicks into action and requests the lost packets. Since it’s just working off whichever packets are lost, it can cope with any type of connectivity loss (though clearly, 100% will be a challenge for any protocol).
Whilst RIST is increasingly seen as a reliable, low-latency part of a streaming workflow, it’s important to understand it’s intended to be used for broadcasters to move video around their own workflows and/or contribute into the cloud. Often, reducing the latency in the contribution part of a system can be a big win in reducing the delivery-to-the-user latency. RIST isn’t intended for a traditional streaming service to thousands or millions of users. For low-latency distribution to users, CMAF is a great option or WebRTC for sub-second latency.
RIST is an ongoing project to create an ARQ technology from existing standards. The RIST Forum brings companies together into a membership group and works to evangelise the protocol, whereas the open specifications are created in the Video Services Forum’s (VSF) ‘RIST activity Group’. To date, they have created two specifications: The simple profile and the main profile. The main profile builds on the good work of the simple and an ‘enhanced’ profile is expected by February 2020.
The Simple RIST profile provides:
- Reliable transport (packet-loss recovery) using ARQ
- Retransmission controls to stop bandwidth use getting out of control
- Link Aggregation (e.g. sending over bonded modems)
- Path Redundancy in the form of SMPTE ST 2022-7
Whilst the simple profile is useful, it’s not until the main profile that we start to approach feature parity with similar protocol SRT which is also able to encrypt data – a key function for contributing over the internet.
RIST Main Profile:
- Null packet suppression (null packets aren’t sent in order to save bitrate)
- Encryption & authentication. Many say that encryption without authentication is pointless.
- Multi-stream tunnelling
- High bit rate support
In conclusion, RIST is a protocol aimed at primary and secondary contribution to allow reliable, low-latency delivery of video and audio as part of a broadcast or streaming workflow. It has security so it can be used for high-value streaming and can feed into a conventional ‘SDI’ workflow in the same way as an OB over satellite feeds into a live programme.
For a deeper dive into RIST, have a look at the talks listed here, some of which introduce topics with RIST and some dig deeper on, for instance the Main Profile.
