Recently, we released a new feature in our low-latency encoders enhancing the capabilities of the SRT protocol while remaining backwards compatible with third-party receivers: SRT Duplicate Streams
This blog post will explain the benefits of SRT duplicate streams and how we are able to make them backwards compatible with third-party SRT receivers. Note that this post isn’t talking about a stream on a second link (i.e SMPTE 2022-7), but a delayed copy of the stream on the same link.
Why use SRT duplicate streams
The goal of SRT is to allow transmission over the public internet. It is getting more common for internet connections to now have substantial amounts of spare capacity vs the video streams being transmitted (e.g a gigabit internet connection at a venue vs a few streams totalling 100Mbit/s). We want to take advantage of this additional network capacity. In traditional RTP video, or protocols based on RTP such as RIST, we would normally send the same packets twice with a delay. The receiver would then use the sequence number to handle the delayed packets as part of its packet reordering process.
Unfortunately the use of RTP has several practical issues in SRT. An obvious problem is that many receivers don’t support RTP in SRT. The second issue is that SRT isn’t aware of the RTP layer, meaning that two receive buffers are needed, one for the SRT layer and one for the RTP layer. This adds unnecessary latency, something not acceptable in interactive applications.
A duplicate stream means a receiver can use the duplicate stream to recover lost packets. The duplicate stream could also be looked at as an “unrequested retransmission”. The benefit of this is that overall latency can be reduced. Traditionally SRT receive buffer (latency) is set to something like 3*RTT or 7*RTT. The fact that there is one forced retransmission means the SRT buffer can be lowered overall, as fewer retransmission attempts are needed (because packets are recovered from the duplicate stream).
The table below shows an example of the latency/bandwidth tradeoff (real world benefits may vary):
| Before (single stream) | After (duplicate stream) | |
| SRT Buffer (ms) | 200 | 100 |
| Bandwidth | 20Mbit/s | 40Mbit/s |
In many cases this is a perfectly reasonable tradeoff. The following graphic shows how a receiver uses the duplicate stream to recover packets:
In fact it is also technically possible to send an SRT stream where the SRT receive buffer is lower than the RTT. This means no actual retransmissions take place but packets can still be recovered from the duplicate stream. There are low-latency applications where this is extremely valuable (with the increased likelihood of packet loss). This opens up new applications for SRT and most importantly remains backwards compatible with the large number of SRT receivers out there.
We are actually adding new functionality to third-party products in the field!
Innovation through an in-house implementation
We are able to implement this change quickly, as a result of our in-house SRT implementation, something we have written about before. It is unclear whether it’s possible to add this to the libsrt implementation as it is extremely complex.
There is one final trick we play to get this across the line. We flag the duplicate packets as being SRT retransmissions. This means the receiver just thinks there are a lot of retransmissions for some reason.
As we have explained in a previous blog post, many professional products are based on “embedded design” principles, often having an extremely weak CPU. A doubling of packet rate could be a problem for embedded devices that can barely process even a single SRT stream. We spent substantial time making sure that third-party devices based on embedded principles were able to process the doubled data rate.
After substantial testing this feature was shipped and is improving transmission capabilities for our customers. Learn more about how our low-latency encoders and decoders are transforming the way professional video is transported.
