Reliable Internet Stream Transport (RIST) with GStreamer

The following contains information about the opensource transport protocol RIST and examples to use it on a GStreamer framework.

Introduction

The RIST project started as a way to address the incompatibility between devices and to define a set of standards for low-latency video streaming. RIST was developed by Video Services Forum (VSF), to ensure a reliable transmission over the Internet. It's typically used on media like news and sports. RIST is based on the RTP standard to multi-vendor interoperability, so it allows compatibility even with non-RIST implementations.

Profiles

RIST has multiple operational profiles, starting with a simple profile. Higher profiles include all the features and functionality of the preceding profiles. The more popular are the Simple (RIST TR-06-1) and the Main profiles (RIST TR-06-2).

Simple Profile

It provides only basic interoperability and packet loss recovery. All configuration is manual and done outside the protocol.

Baseline Protocol: RIST Simple Profile provides only basic interoperability and packet loss recovery. To ensure a level of interoperability between RIST and non-RIST implementations, RTP is used as the baseline protocol for media transport and RTCP for feedback/control messages, as specified in RFC 3550.

RTCP Support: RIST senders and receivers should use RTCP. For senders, RTCP is used to keep state on NAT (Network address translation) devices along the path. For receivers, RTCP is used to request lost packet re-transmissions. The additional information included in the RTCP packet may be used sender and receiver devices to achieve better network performance.

NACK-Based Recovery Protocol: RIST uses a NACK-based Selective Retransmission protocol to recover from packet loss. So, once packet loss is detected, receivers request a retransmission of the lost packet or packets as follows:
- There's a reciever buffer which is a FIFO for the arriving packets, this FIFO is divided into sections. The first one is the reorder section, here the "out-of-order-packets" are handled, then they continue to the re-transmission reassemble section. At the boundary of these 2 sections the packet loss is detected by checking discontinuities in the RTP sequence number. On the re-transmission reassemble, the re-transmissions are requested.
- For an implementation looking for providing minimum possible delay it's convenient to reduce the reorder-section, but it could cause extra re-transmissions. In the other hand, having a bigger reorder section allows more time to accommodate the worst case delay of the packets.

Bonding Support: Bonding is a feature to split or replicate packages if needed. It is used for example when the network is congested and we like to keep the quality of the streaming. Bonding allows to enable a multi-link setup to perform a network redundancy. RIST Receivers implementing bonding support combine the packets received from multiple channels in order to reconstruct the original media stream. There are 2 types of bonding:
- Load Sharing: Split the RTP stream between multiple channels in order to combine their bandwidths.
- Seamless Switching: Replicate the RTP stream between multiple network connections in order to increase reliability.

Main Profile

The Main Profile includes the features from the Simple Profile, along with the following new ones:

Stream Multiplexing and tunneling support: The objective of stream multiplexing and tunneling is to provide the ability to combine all the communication between two RIST devices into a single UDP port.

Encryption Support: RIST senders and receivers use DTLS version 1.2 and Pre-Shared Key Encryption to secure their communication and authenticate the endpoints.

NULL Packet Deletion: Is typical to transmit MPEG Transport Streams when using RIST, however 3 to 5% are NULL packets. To save bandwidth, RIST can transmit a shorter RTP packet (droping the NULL packets) and use the extension header to indicate where the NULL packets need to be inserted, so the receiver can add them to the RTP packet, to keep the stream timing intact.

High Bitrate Operation: The RTP sequence number is only 16 bits, when increasing the bitrates the latency is increased a lot. This Main profile allows sequence number extension to support high bitrates above 100 Mbps.

GStreamer Implementation

GStreamer Plugins Bad offers ristsrc and ristsink elements intended to be used on RIST streaming applications. The RIST plugin requires at least GStreamer 1.18.
A typical RIST transmitter pipeline would payload an MPEG Transport Stream (TS) into RTP and send it using ristsink element. On the other endpoint, it can be received using ristsrc element on a custom pipeline or using gst-play-.1.0 rist://<IP>:<PORT>.

These Gstreamer elements support most of the features of Simple and Main profile:

RTP/RTCP support: Both elements are GstBins built around the rtpbin element. It exposes some properties: max-rtcp-bandwidth, min-rtcp-interval.
Re-transmission features: It supports the mentioned re-transmission feature and exposes some properties: receiver-buffer, reorder-section, max-rtx-retries.
Bonding support: The bonding is enabled by adding more than one IP addresses to the bonding-addresses property. It also supports the bonding-method property to select bonding type.
NULL Packet Deletion: By using the property drop-null-ts-packets.
Sequence number extension: By using the property sequence-number-extension.

[Note]: The tunneling, multiplexing and encryption features are not supported.

Simple RIST Streaming

The following example send H264 video on a MPEG TS over IP Address "192.168.1.32" port "8000". The receiver demuxes and decodes the video to display it.

# Server Pipeline
gst-launch-1.0 videotestsrc is-live=true ! video/x-raw,width=640,height=480 ! x264enc key-int-max=30 ! mpegtsmux ! tsparse set-timestamps=1 smoothing-latency=40000 ! rtpmp2tpay ! ristsink address=192.168.1.32 port=8000

# Client Pipeline
gst-launch-1.0 ristsrc port=8000 ! rtpmp2tdepay ! tsdemux ! h264parse ! avdec_h264 ! queue ! videoconvert ! xvimagesink

Bonding RIST Streaming

The following example does the same as the previous example, but it enables the bonding to duplicate the streaming on a different network, so if one is down the streaming can still reach the receiver endpoint to avoid interruption.
So, the streaming is send over "192.168.1.32:8000" and a copy is set over "127.0.0.1:8000". The receiver is listening to both as well, then the video is again demuxed and decoded to be displayed

# Server Pipeline
gst-launch-1.0 videotestsrc is-live=true ! video/x-raw,width=640,height=480 ! x264enc key-int-max=30 ! mpegtsmux ! tsparse set-timestamps=1 smoothing-latency=40000 ! rtpmp2tpay ! ristsink bonding-addresses="192.168.1.32:8000,127.0.0.1:8000" bonding-method="broadcast"

# Client Pipeline
gst-launch-1.0 ristsrc bonding-addresses="192.168.1.32:8000,127.0.0.1:8000" ! rtpmp2tdepay ! tsdemux ! h264parse ! avdec_h264 ! queue ! videoconvert ! xvimagesink

Using H264 Payload (Gst-1.24)

Since GStreamer 1.24, it's possible to use a dynamic payload type. It can be done through setting the caps property or one can use the encoding-name property and the element can work out the caps from it. Here is an example:

# Server Pipeline
gst-launch-1.0 videotestsrc is-live=true ! video/x-raw,width=640,height=480 ! x264enc key-int-max=30 ! h264parse ! rtph264pay ! ristsink address=192.168.1.32 port=8000

# Client Pipeline
gst-launch-1.0 ristsrc port=8000 encoding-name="h264" ! rtph264depay ! h264parse ! avdec_h264 ! queue ! videoconvert ! xvimagesink

The elements currently supports the two bonding methods mentioned before by setting bonding-method property:

broadcast: all the packets are duplicated over all sessions (Seamless Switching). A tee element is used to duplicate the packets.
round-robin: packets are evenly distributed over the links (Load Sharing). A round-robin element is used in this case.

It's also possible to implement its own dispatcher element and configure it using the dispatcher property.

Optimizing Network Kernel Settings

If packet losses are observed at the receiver side, it could be because Network Kernel Settings are limited. For optimal performance to avoid packet losses, modify the network Kernel settings to increase the buffer size at the receiver endpoint.

Check the default settings

cat /proc/sys/net/core/rmem_max
cat /proc/sys/net/core/rmem_default

Run the following commands to increase the buffer size:

sudo sysctl -w net.core.rmem_default=2129920
sudo sysctl -w net.core.rmem_max=10000000

References

For direct inquiries, please refer to the contact information available on our Contact page. Alternatively, you may complete and submit the form provided at the same link. We will respond to your request at our earliest opportunity.

Links to RidgeRun Resources and RidgeRun Artificial Intelligence Solutions can be found in the footer below.

❯