SRT for contribution over bad networks: latency, overhead and encryption

SRT is the protocol to use when a camera or encoder must send live video over the public internet or a mobile network. It runs over UDP, resends lost packets, and gives every packet a fixed deadline: the latency you set. Set that latency to three or four times the round-trip time, leave bandwidth headroom for resends, and turn on encryption with a passphrase.

How SRT survives loss

The receiver tracks sequence numbers and asks for anything missing (a NAK). The sender keeps recent packets and resends them. Each packet carries a timestamp, and the receiver plays it out exactly latency milliseconds after it was sent. A resend that arrives before that deadline fixes the loss invisibly; one that would arrive later is dropped, and the decoder sees a short glitch instead of a stall.

This is the difference from RTMP. RTMP over TCP never drops anything, so one lost packet holds back everything behind it and the delay keeps growing. SRT trades a rare glitch for a delay that never moves.

Setting the latency

1. Measure the round-trip time from the encoder to the server, for example with ping.
2. Multiply by 3 to 4. A 60 ms round trip gives 180 to 240 ms.
3. Never go below about 120 ms, SRT's default.
4. On a lossy or mobile link, raise it until the receiver's statistics show no unrecovered loss. One to two seconds is normal for cellular bonding or intercontinental links.

Both ends negotiate and use the larger of their two latency values.

Overhead: the bandwidth for resends

Resends need spare bandwidth. SRT limits them with an overhead budget, 25% above the stream's bitrate by default. A 6 Mbit/s stream therefore needs about 7.5 Mbit/s of reliable uplink. On a link that loses more than a few percent, raise the budget or lower the bitrate; if the link cannot carry the stream plus its resends, no latency setting will save it.

Encryption

Give both ends the same passphrase (10 to 79 characters) and key length (16, 24 or 32 bytes: AES-128, 192 or 256). SRT derives the key from the passphrase and encrypts every payload. A receiver with the wrong passphrase gets nothing it can decode.

Caller, listener and stream IDs

One side listens on a UDP port and the other calls it. For contribution to a server, the server listens and the encoder calls. The streamid tells the server which stream this is and carries the credentials, so one port serves every stream.