June 21, 2019

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.

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.

SRT Publisher Assistance Security Set

Nimble Streamer has flexible security and management feature set for SRT receiver Listen mode:

  • Accept streamid parameter with "application/stream" format.
  • Make per-application and per-stream authentication with user and password.
  • Apply any SRT parameters like latency and maxbw to each individual stream and even individual publisher.
  • Apply allow and deny lists for IP addresses on server and stream level.
  • Manage published streams via publish control framework.

Read more details in feature overview.

Related documentation

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