SRTLA bonding for stable IRL streams
Bond multiple networks (LTE + Wi‑Fi), when bonding helps, and how to tune buffer and packet loss.
How to set SRT latency and buffer correctly
Short answer: SRT latency is a recovery window for jitter and lost packets – not simply “wasted delay.” On a good network, roughly 4× RTT is a useful rule of thumb; mobile links and burst loss often need substantially more. For mobile IRL, 1,000–2,000 ms is a sensible starting range. IRL.com.de recommends staying at roughly 2,500 ms or below whenever possible so the added transport delay does not push the stream too far away from a live feel. This is a practical recommendation, not a technical SRT maximum.
What SRT latency actually does
SRT keeps packets in sender and receiver buffers. That leaves time to request a missing packet again and place the retransmission back into sequence before delivery. A larger window can absorb more network variation, but it deliberately increases transport latency.
The negotiated latency is influenced by both endpoints; during connection setup the relevant higher value is used.
The 4× RTT rule of thumb
Haivision's documentation suggests about 4× RTT for a relatively good network with roughly 0.1–0.2% loss and no significant burst loss.
| Measured RTT | 4× RTT starting point | Practical interpretation |
|---|---|---|
| 50 ms | 200 ms | Reasonable for a clean, stable network |
| 100 ms | 400 ms | May still be tight with mobile spikes |
| 250 ms | 1,000 ms | More recovery time for difficult links |
| 500 ms | 2,000 ms | High delay, but considerably more recovery room |
Burst loss can require more buffer than the simple RTT calculation. If an outage lasts longer than the available recovery window, SRT cannot recover the missing data in time.
What value should I use for IRL streaming?
- Very stable LAN/fixed line: start relatively low and test against real RTT and loss.
- Good 5G/LTE: a few hundred milliseconds may be enough; watch for spikes.
- Mobile IRL with changing coverage: 1,000–2,000 ms is a conservative and often useful starting range.
- Difficult mobile route: increase gradually, but try to remain below roughly 2,500 ms if keeping the stream feeling live is important.
- Extremely unstable link: more than 2,500 ms can still be technically sensible when stability matters more than the added delay.
Practical limit, not protocol limit: Around 2,500 ms is an IRL.com.de recommendation for preserving a live feel. Above that, the SRT recovery window alone is already several seconds, before encoding, relay, platform and player delay are added. SRT itself technically allows higher values.
How do I know the buffer is too small?
- Skipped/dropped packets rise even though there is still usable bandwidth.
- Short network spikes immediately produce visible artifacts or freezes.
- The stream is stable on a quiet network but fails when mobile conditions fluctuate.
If loss instead rises in large bursts or the link is continuously overloaded, “more buffer” does not fix the root cause. Lower the bitrate, improve the links, or use SRTLA bonding when multiple networks are available.
Practical tuning workflow
- Observe RTT and packet loss during a realistic test.
- Start around 4× RTT if the network is relatively clean.
- Increase gradually when mobile burst loss still exceeds the recovery window.
- For IRL, keep the smallest stable value below roughly 2,500 ms whenever possible.
- If stability only arrives well above 2,500 ms, consciously trade lower live responsiveness for extra resilience.
- If a large buffer is still unstable, optimize bitrate or network paths instead.