Controlled SRT experiment
Useful SRT latency is not a number borrowed from another network. It is the smallest recovery window that survives the measured RTT and loss behavior of the real path while still meeting the production delay budget.
The experiment changes one control at a time, correlates transport counters with decoded media and keeps endpoint roles and versions in the same test record.
Define the path and acceptable end-to-end delay
The path should be explicit from sender application and network interface to receiver application and decoded output. Its record includes regions, links, VPNs or mobile segments, firewalls, endpoint roles, SRT library or application versions, payload and approximate media rate. It also names the production consequence of delay: conversation, return audio, switching or passive viewing.
An acceptable end-to-end range needs to exist before transport tuning begins. SRT receiver latency is a time budget used by recovery; the effective setting and peer negotiation must be checked on the actual path rather than treated as a universal quality preset. A transport setting is only one component of the full glass-to-glass result.
Capture RTT and loss behavior
Observe RTT over time instead of taking one sample. Record a quiet baseline, normal operating variation and the periods where the production historically fails. Capture loss and retransmission fields from the same session and interval. Reset or reconnect boundaries must be visible so cumulative counters are not subtracted across different sessions.
SRT is an open-source transport protocol for live video and audio; it uses UDP and ARQ-based retransmission, with optional AES encryption. Those mechanisms make recovery possible, but they do not create spare link capacity. Compare measured media rate with the path and watch for sustained congestion separately from short loss bursts.
Interpret the measured counters for field classes and units. Keep this tuning log focused on how observed path behavior changes the selected latency.
Choose a starting recovery window
A defensible starting point comes from the observed RTT range, the duration of loss bursts and the delay budget, with the source of every input recorded. It is not a universal multiplier or guarantee. Because peers, application labels and units can differ, the effective setting and negotiation must be checked in current SRT documentation and endpoint logs.
Review SRT mode and recovery if Caller, Listener, Rendezvous or ARQ behavior is unclear. Then Configure the tested SRT endpoint without changing bitrate or routing during the baseline. The starting value remains a hypothesis, not the answer.
Reproduce the risky condition
The most useful test runs on the network where the feed will operate, or uses an approved impairment method that resembles the observed risk. One loss or delay pattern at a time keeps its parameters attributable, and an unimpaired run provides the baseline. An artificial test so extreme that it teaches nothing about production should be avoided.
During the run, the record captures RTT, loss and retransmission deltas, sender and receiver state, media rate and decoded picture/audio. Inspect decoded output in Multiview when it is the approved receiver surface. Freezes, audio gaps, drift and reconnects complete the evidence because counters alone cannot describe the viewer result.
- Timestamp the impairment start and end.
- Keep the session identity visible.
- Mark counter resets.
- Record the effective latency, not only the requested UI value.
- Repeat the same pattern for comparison.
Adjust one latency control at a time
Receiver latency should move in controlled steps while encoder rate, packet size, region and other recovery settings stay fixed. Each step repeats the same baseline and risky condition, then compares recovery deltas, late or unrecovered loss when exposed, and decoded output.
A larger value can give retransmission more time, but it also adds delay. A smaller value can improve interaction and still fail when a replacement packet arrives too late. The accepted point must satisfy both the transport observation and production delay budget. Sustained congestion is a signal to stop treating latency as the only control.
| Run | Latency peers | RTT/loss condition | Recovery deltas | Decoded result |
|---|---|---|---|---|
| Baseline | Exact values | Normal path | Timed interval | Picture/audio/delay |
| Risk | Same values | Reproduced event | Timed interval | Visible outcome |
| Next step | One change | Same event | Comparable interval | Accept or reject |
Approve the smallest stable tested setting
The accepted value is the smallest tested setting that survives the defined condition and stays within the end-to-end delay range. It should run long enough to include normal variation. Any operating margin and the trigger for a new experiment—such as route, region, bitrate or application-version change—belong in the decision.
Operators also need a response for drift outside the tested envelope. That may mean returning to a previously tested value, reducing media load through a separate rate-control procedure or changing route. It should never become an unlimited increase during an incident without recording the new delay and peer negotiation.
A representative operating window provides a stronger confirmation than a quiet lab period alone. Preserving the baseline lets later network or application changes be compared with the accepted RTT range, loss event and decoded result.
The final evidence is a timestamped before/after run with endpoint roles, SRT library or application versions, RTT range, loss event, latency on both peers, retransmission deltas, decoded picture/audio and accepted setting. Rejected runs remain useful: they explain why the value exists and keep future operators from repeating an unsafe shortcut.
