Video: The next enhancement for RIST

Continuing the look at RIST, the developing protocol which allows for reliable streaming over the internet – even in the event of packet loss, we have a look at a key feature on the roadmap.

The core proposition of RIST is to produce an interoperable protocol which brings the internet into the list of ways to contribute and distribute low-latency video. It’s resilient to packet loss due to it’s ability to re-request packets which have been lost yet is light enough for video streaming. In another talk at IBC, we learn about the latest developments which have added security and many other features to the list of capabilities.

Here, Adi Rozenberg from VideoFlow explains how this will further be extended by upcoming work to allow the source stream to reduce in bitrate in response to reduced capacity in the network. With RIST’s ARQ – the technology which requests missing packets – we find that the retransmissions can actually aggravate bitrate constrictions particularly when they are permanent. Adi proposes the only real way to solve lack of bandwidth issues is to reduce the bitrate of the source.

RIST already includes NULL packet removal so that NULL packets aren’t transmitted and are re-inserted at the remote end. This is usually a great start in reducing the bitrate of the stream. However more is needed, we need a way to tell the encoder to reduce the bandwidth of the video stream itself. This can be accomplished by RTCP.

Adi identifies the problem of identifying when extra bandwidth has returned as a reduction of bandwidth is quickly and easily signalled with retransmissions, but excess bandwidth silently returns. The system gradually increases the encoder bandwidth to always be probing the current balance of bandwidth and bitrate.

This works well when there is a single encoder and a single decoder. When there are multiple decoders, life is more difficult. The solution offered to this is to create a ladder of bitrates all of which are adaptable. Now the destination can switch between profiles. This can be extended to MPTS (Multi-Program Transport Streams) whereby, depending on the destination, services in the MPTS are dropped in order to recover bandwidth. A mechanism is used which prioritises services depending on the destination (i.e. German channels are de-prioritised on delivery to France).

The session ends with a Q&A on stream switching details and use in stat mixing.

Watch now!
Speakers

Adi Rozenberg Adi Rozenberg
CTO,
VideoFlow