Efficient usage of SRT latency and maxbw parameters

We continue educating streaming people on SRT protocol usage. It's a streaming protocol which adapts to the network conditions, helps compensate for jitter and other fluctuations with error recovery mechanism to minimize the packet loss. This leads to the lost packets re-transmission, which increases the bandwidth usage between sender and receiver.

We'll take a look at "latency" parameter which is tightly related to the re-transmission process in general.

The "latency" parameter specifies the delay which is used if the packet reached the destination quickly (and therefore it's way ahead of "time to play"). But when the packet was lost, this gives it an extra time to recover the packet before its "time to play" comes. Original packet delivery takes some round-trip time (RTT), so it will take another RTT to send the correction. And if some issues happen again on its way to receiver, the sender will re-transmit it again and again until it's correctly delivered, spending time during this process.

So too small value of "latency" may cause the denial of re-transmission. Let's suppose you have some RTT from sender to receiver equal 200ms, and your "latency" is set to 300ms. Obviously, the receiver won't be able to get any re-transmission in case of first transmission because the latency "window" will close.

The SRT community recommends setting "latency" as follows:

• Your default value should be 4 times the RTT of the link. E.g. if you have 200ms RTT, the "latency" parameters should not be less than 800ms.
• If you'd like to make low latency optimization on good quality networks, this value shouldn't be set less than 2.5 times the RTT.
• Under any conditions you should never set it lower than default 120ms.

The "latency" value can be set on any side of transmission:

• sender;
• receiver;
• both sides.

The effective latency will be the maximum value of both sides, so if you don't set it on sender (so it'll have default 120ms) and 800ms on receiver, the active value would be 800ms.

We've previously shown how you can control the maximum bandwidth available for transmission over SRT using "maxbw" parameter. As you can see, you need to be aware not only about the bandwidth on your sender, but also latency settings.

So we highly encourage you setting both "latency" and "maxbw" parameters during SRT setup. Otherwise you will face one of these issues:

• When you set "maxbw" to cover all network problems, the latency can be too low to tolerate the losses.
• When you set proper "latency" without "maxbw", it will cause exhaustion of bandwidth.

If you don't know the exact values of your expected bandwidth, please set maxbw to 0 to let the SRT library auto-select bandwidth efficiently and handle re-transmission of lost packets.

Both configuration options are available for SRT setup in Nimble Streamer.

Please refer to SRT setup article to get familiar with the general setup process. Once you complete all required steps, use custom parameter fields to define appropriate entries as shown below.

The "maxbw" is defined in bytes per second, NOT bits per second. So if you'd like to set maximum bandwidth to 2Mbps, you'll have to specify 250000 as your designated value. This is an SRT-specific approach to value definition. The "latency" is defined in milliseconds.

Larix Broadcaster mobile app allows streaming via SRT with defined "maxbw" and "latency" as well.

If you have any questions regarding SRT setup and usage, please feel free to contact our helpdesk so we could advise.

Check out SRT support in Softvelum products to see what might help your company to utilize SRT the best way.

Follow us in social media to get updates about our new features and products: YouTube, Twitter, Facebook, LinkedIn, Reddit, Telegram

Related documentation

Nimble Streamer SRT feature set, SRT setup in Nimble Streamer, SRT FEC (forward error correction) in Nimble Streamer, Haivision blog: Reliable Low Latency Delivery with SRT+SLDP, Glass-to-glass SRT delivery setup, SRT in other Softvelum products