SRT settings
Use these settings to establish an SRT session and give it enough recovery time and bandwidth for the production path.
Choose the Connection Mode
Section titled “Choose the Connection Mode”SRT connection mode controls how the endpoints establish the session. It does not determine which endpoint sends the media.
- Caller initiates the connection to a known remote address and port. Pair it with a listener. Caller is usually the practical choice for an endpoint behind a firewall or NAT because it starts outbound traffic.
- Listener binds to a local UDP port and waits for a caller. Make that port reachable through the host firewall, cloud security group, and any NAT. A listener can be the media source or destination.
- Rendezvous has both endpoints initiate the connection. Configure rendezvous on both ends, give each end the other endpoint’s address, and use the same UDP port unless the implementation explicitly supports separate local and remote ports. Rendezvous can traverse some stateful firewalls, but it requires port preservation and does not work through every NAT or firewall.
Set SRT Latency
Section titled “Set SRT Latency”SRT latency is the network recovery buffer. It gives a late or retransmitted packet time to arrive before the receiver releases that point in the stream. It is only one part of the production’s total glass-to-glass delay.
- Measure round-trip time (RTT) across the path under realistic production conditions.
- Start with a latency of approximately four times RTT on a reasonably good network. For example, a stable 50 ms RTT suggests a starting latency near 200 ms.
- Test long enough to include normal jitter and congestion. Increase latency if packets arrive too late to be recovered. Reduce it only after the path remains stable with margin.
- Re-test when the route, ISP, access network, or production location changes.
During the SRT handshake, the endpoints exchange their latency requirements. For each receiving direction, SRT uses the greater of the receiver’s configured receive latency and the latency requested by the sender for its peer. Products that expose one Latency value commonly apply it to both requirements, so the higher value configured at either endpoint wins. Reconnect the session after changing it; lowering only one endpoint will not reduce the negotiated value while the other endpoint still requests more.
More latency provides more time to recover loss and jitter, but adds delay. A low value does not improve the underlying network and may cause visible errors when retransmissions arrive too late.
Set Maximum Bandwidth
Section titled “Set Maximum Bandwidth”Max Bandwidth is the ceiling available to the SRT sender for media, protocol control traffic, and retransmissions. It is not negotiated between the endpoints.
- Determine the stream’s expected peak audio/video bitrate. Use the peak, not only a long-term average, for a variable-bitrate encoder.
- Add recovery overhead. The SRT reference implementation recommends using the anticipated input bitrate with 25% overhead as a practical starting point. A 10 Mbps stream would therefore need a maximum bandwidth of about 12.5 Mbps.
- Keep the result below the sustained bandwidth actually available on the narrowest part of the path. Leave capacity for other traffic sharing that link.
- Set the ceiling on the sending endpoint. For a bidirectional SRT session, size each sender independently.
- Test with realistic packet loss. If the ceiling is too close to the media bitrate, SRT cannot retransmit quickly enough. If it is higher than the path can sustain, retransmissions can add congestion instead of repairing the stream.
Confirm whether an endpoint expects bits per second or bytes per second before entering a value. SRT’s low-level SRTO_MAXBW option uses bytes per second, but product interfaces may present different units.
Worked example: 1080p at 8 Mbps over a 100 ms RTT path
Section titled “Worked example: 1080p at 8 Mbps over a 100 ms RTT path”Assume the stream’s peak combined video and audio bitrate is 8 Mbps and the measured round-trip time between sender and receiver is approximately 100 ms.
- Calculate the starting latency:
4 × 100 ms RTT = 400 ms. - Calculate 25% recovery overhead:
8 Mbps × 0.25 = 2 Mbps. - Add the stream and recovery allowance:
8 Mbps + 2 Mbps = 10 Mbps. - Configure Latency to start at 400 ms and Max Bandwidth to 10 Mbps, if the interface uses bits per second.
If an endpoint expects bytes per second, convert the result by dividing by eight: 10,000,000 bits/s ÷ 8 = 1,250,000 bytes/s. Confirm the available path can sustain more than 10 Mbps and still leave room for other traffic. Then test under realistic conditions; increase latency if retransmitted packets still arrive too late, or increase the bandwidth allowance only when the path has spare capacity and recovery traffic is being constrained.
For protocol detail and deployment examples, see the SRT Alliance Deployment Guide. The current open-source SRT documentation also describes latency negotiation and maximum-bandwidth options.
If the session does not establish, follow An SRT connection won’t establish.