The SRT latency box is not a speed setting. It is the amount of time you give the protocol to notice that a packet went missing, ask for it again, and get it back before the picture needs it. Set it too small and the stream freezes on every bad second of cellular. Set it sensibly and the same bad second is invisible.
For IRL the sensible number is bigger than the studio number. Here is what it does, what to type in, and how to tell whether it is the thing that needs changing.
What the number actually is
SRT runs over UDP. When a packet is lost, the receiver notices the gap and asks the sender for that packet again. The latency value is how long the receiver is willing to wait for that answer before it has to give up and play what it has. Anything that arrives inside the window is put back in order and the viewer never sees the loss. Anything that misses the window is dropped, and that is the freeze or the smear of blocks you see on a rough connection.
So the window has to be wider than a full round trip, with room for more than one attempt. Haivision, who wrote the protocol, put it as a multiple of the round trip time: roughly three to four times on a clean link, and more as packet loss climbs.
The part people miss is that it is a two-sided setting. Your encoder declares a latency, the relay declares one, and the handshake uses the larger of the two. Turning your encoder down below the relay's value changes nothing, and turning it up always takes effect.
Why the IRL number is bigger
A wired studio link has a steady round trip. A phone walking through a city does not. The average round trip to a nearby relay might be under a tenth of a second, but a tower handover, a crowded cell, or a modem waking back up can push one round trip past half a second and stack a few of those in a row. The window is not sized for the average. It is sized for the spike.
With SRTLA bonding there is a second job for the same window. SRTLA spreads your packets across every modem you have. When one modem goes dark, the packets that were in flight on it are gone, and SRT asks for them again. SRTLA sends those retries over the modems that are still healthy. The latency window is the time budget for that reroute. A tight window means a dead modem costs you a freeze even though you have two more working. A roomy window means it costs you nothing visible. That is most of the reason bonding feels so much smoother than a single SRT link on the same phone.
What to set
| Where | Setting | Notes |
|---|---|---|
| Belabox (SRTLA) | 2000 ms | The default. Go up, not down, if a route is rough. |
| Moblin on iPhone (SRTLA) | 3000 ms | The default. Leave it; it is already on the roomy side. |
| IRL Pro on Android (SRTLA) | 2000 ms | Same field as Belabox, same starting point. |
| LiveU Solo Pro (SRT) | 2500 ms | What the dashboard shows for this encoder. |
| Larix (SRT) | 2500 ms | Set automatically when you open the connection from the dashboard. |
| OBS media source pulling the relay | latency=2000000 | Microseconds, not milliseconds. This is two seconds. |
If you only take one thing from the table: there is no good reason to go below 2000 ms on a cellular route, and there is rarely a reason to go above 4000 ms. Between those, higher is safer and the cost is fractions of a second of delay that nobody in chat can feel.
The OBS side counts in microseconds
OBS reads SRT through FFmpeg, and FFmpeg's latency option is in microseconds. Two seconds is 2000000. Typing 2000 gives you two milliseconds, which is no recovery window at all, and the pull will stutter even on a perfect home connection. The full pull URL is in the OBS setup guide.
Reading the symptoms
Most latency questions are really "something is wrong, is this the knob". Usually it is one of three things and only one of them is the latency.
| What you see | What it means | What to change |
|---|---|---|
| Short freezes or blocky frames while the bitrate graph stays healthy | Packets are missing the window | Raise SRT latency by 500 ms and test again |
| Bitrate drops and the picture softens, but it keeps moving | The adaptive bitrate is doing its job on a thin link | Nothing on latency. This is the trade working. |
| The stream ends completely | The connection died, not the buffer | Drop protection: your own OBS holding the broadcast. See keep your stream live. |
The first row is the only one the latency setting fixes. The second row is normal and the third row is a different problem entirely. Raising latency to fight a disconnect does nothing, because there is no connection left to recover on.
SRT latency is not your viewer delay
The window on your encoder is one hop in a chain. The relay hands the stream to your OBS over a second SRT hop with its own window. OBS holds a network buffer, encodes, and pushes to the platform. The platform ingests, transcodes, and the player buffers on top of that.
| Stage | Roughly |
|---|---|
| Encoder SRT window | 2 to 3 s |
| Relay to OBS SRT window | 2 s |
| OBS network buffer and encode | under 1 s |
| Platform ingest, transcode, player | several seconds |
Cutting the first row from 2500 to 1000 saves a second and a half out of a chain that runs well past that, and it buys that second with every freeze the window can no longer absorb. People forgive a short delay. They leave when the picture keeps stopping. If chat timing genuinely matters for a segment, the platform's low latency mode moves the total far more than the SRT number does.
How to tune it without guessing
- Set the encoder to the number from the table and leave it alone.
- Stream the worst part of your route: the tunnel, the crowd, the train platform. Not your living room.
- If the picture freezes while bitrate holds, raise latency by 500 ms and run the same route again.
- Change one thing at a time. Latency, bitrate, and resolution all move the same symptoms, and adjusting two together tells you nothing.
- Keep the local recording. Watch the motion and the audio back rather than trusting a green number on a dashboard.
The relay is the other half of the setting
Your encoder only decides one side. Our relay runs a relaxed latency profile by default, built for bonded cellular uplinks rather than a studio link, so a sane encoder value lands on a receiver that expects rough conditions. Pair that with pulling the relay into your own OBS and the field connection stops being the thing that ends your broadcast.
Still choosing a protocol? SRTLA vs RTMP covers when SRT alone is enough and when you need bonding.
FAQ
- What SRT latency should I use for IRL streaming?
- Start at 2000 to 2500 ms on the encoder side and leave it there until the stream has proven stable on the worst part of your route. Belabox defaults to 2000 ms and Moblin to 3000 ms, and both are fine as they are. Our dashboard hands out 2500 ms for single-connection SRT encoders like the LiveU Solo Pro and Larix.
- Does the SRT latency need to match on both ends?
- No. Both ends declare a value in the handshake and the connection uses the larger one. That is why setting your encoder below whatever the relay uses does nothing, and why the OBS pull can be tuned separately from the encoder side.
- Will 2500 ms make my stream feel slow for chat?
- Not noticeably. The SRT window is one piece of a chain that already includes a second SRT hop into OBS, OBS's own buffer, and the platform's ingest and player delay. Cutting the encoder window in half saves about a second out of a chain that runs well past that.
- Why does the OBS media source want 2000000 instead of 2000?
- OBS reads the SRT URL through FFmpeg, and FFmpeg takes latency in microseconds. 2000000 is two seconds. Typing 2000 there gives you two milliseconds, which is effectively no recovery window at all.