What SRT latency should I actually set?

Almost every SRT problem that looks like "bad quality" is one of two things: a buffer too small to finish a retransmission in time, or a link with no room for the retransmissions at all. They look identical on screen and have opposite fixes, which is why guessing wastes so much time.

What latency actually buys

When a packet goes missing, the receiver asks for it again. That request travels back, the packet travels forward: one round trip, minimum. The receiver can only wait if it is holding a buffer of already-received video — and that buffer is what latency sets.

So the question "what latency should I use" is really: how many round trips of grace do I need before I give up on a packet?

• Buffer smaller than one RTT: recovery is impossible. The packet arrives after it was due.
• Buffer at 3× RTT: one loss recovers comfortably, a second attempt on the same packet still fits.
• Buffer at 8–10× RTT: survives bursts, at the cost of everything arriving that much later.

Measure two numbers first

RTT. ping the server you will actually stream to, from the machine and network you will actually use, at the time of day you will use them. Take the average, and note the worst.

Loss. From the same place:

ping -c 200 de.inoutsrt.com

The summary line gives packet loss over 200 tries. Under 1% is a good wired link; 1–3% is ordinary Wi-Fi or a decent mobile connection; above 5% needs fixing rather than buffering.

Then put both numbers into the latency calculator — it applies Haivision's published deployment table:

The right-hand column is the part people miss: at 10% loss, your link has to carry 15% more than your video bitrate, or the retransmissions themselves start getting lost.

Worked examples

Studio to studio, same country, fibre. RTT 18 ms, loss 0.2%. Multiplier 3 → 54 ms, but SRT's practical floor for a short path is about 120 ms; use 150 ms and enjoy near-instant video.

Europe to the US, wired. RTT 110 ms, loss 0.5%. Multiplier 3 → 330 ms; round up to 400 ms for peace of mind. Note the delay is dominated by distance, not by your settings.

4G from a stadium. RTT 45 ms but bursty loss hitting 8% during crowd peaks. Multiplier 6 → 270 ms, but bursts are exactly what the table warns about; run 800 ms and drop the bitrate. On a busy cell, a smaller picture that survives beats a big one that stutters.

Talkback, two directions. Every hop adds its own buffer. Two SRT legs at 300 ms is 600 ms before the decoder even starts, and a natural conversation dies past roughly a second round trip. Budget it with the delay tool before promising anyone "real-time".

Is my problem buffer or bandwidth?

A quick test that separates them:

1. Raise latency to 1000 ms and stream again. Picture cleans up? Your problem was buffer — now walk it back down to the smallest value that stays clean.
2. Still breaking up? No buffer can invent capacity you do not have. Drop the bitrate by a third and retest. If that fixes it, the link is the limit.
3. Neither helps? Something is dropping UDP in bulk — a captive portal, an overloaded CPE, a router with SIP/ALG-style meddling. Pull our test signal from that same network: if the bars stutter too, the network is guilty and no encoder setting will save you.

Common mistakes

Setting latency equal to RTT. Mathematically hopeless, yet it is the most common setting people try, because it "sounds like enough".

Different values on each end. SRT takes the larger of the two, so your careful 200 ms is silently 2000 ms because the decoder still had a default from last year.

Latency as a quality knob. It does not change compression or sharpness. If the picture is soft, that is bitrate and encoder settings; latency only decides whether losses are repaired in time.

Giant buffers everywhere, permanently. A 2-second buffer hides a broken link — right up to the show where the link is 10% worse and there is nothing left in reserve. Fix the path, then set the buffer that path deserves.