SRT and RIST ingest¶
SRT and RIST carry the signal across a network you do not control: over the internet, between cities, from an outside broadcast unit. Losses in such a network are inevitable, and both transports recover them by retransmission for as long as there is time left to do so.
SRT¶
On the Sources tab press + Add source and choose the SRT protocol. The station waits for a connection on a dedicated UDP port and the sender connects to it.
| Field | What it sets |
|---|---|
| Host, Port | the address and UDP port we wait for the connection on |
| Passphrase | the AES encryption key; on a mismatch the connection is refused at the handshake |
| Stream ID | the expected identifier of the sender |
| Receive latency (ms) | the loss recovery budget (see below); 120 by default |
| Handshake timeout (ms), Peer timeout (ms) | the connection and inactivity timeouts |
An srt:// address pasted whole is split into the fields, and the SRT URL assembled back is shown next to them — that is what you copy and give to the sender.
Latency is a budget, not delay for its own sake¶
Receive latency sets how long a packet waits in the receive buffer before it is handed out. A lost packet only makes it back in time if the retransmission request and the answer fit into that window — hence the practical rule written right in the field's hint: no less than three or four RTTs to the source.
On a link with a 100 ms RTT the standard 120 ms leaves room for no recovery attempt at all: a loss becomes a hole in the signal. The price of raising it is honest and predictable — exactly that much delay on the output and memory for the receive buffer.
The value is chosen from the measured RTT rather than from a feeling: the RTT and its variation are in the connection counters.
What the transport does¶
The full ARQ mechanism is implemented: acknowledgements (ACK/ACKACK), retransmission requests (NAK) with a period tuned to the measured RTT, in-order delivery out of the latency buffer, dropping of hopelessly late packets (too-late drop), keepalive for idle connections.
The practical consequence for a headend: losses on the link do not have to become defects in the signal. While the budget suffices, the hole is closed by retransmission and never reaches the output. When the budget does not suffice, the counters say so — the too-late drops grow, not only the retransmits.
RIST¶
The RIST protocol is added with the same + Add source. There are two differences from SRT, and both are visible in the form:
- RIST profile — Simple (a pair of ports), where media and RTCP take neighbouring ports (the media port must be even), or Main (a GRE tunnel), where a single Tunnel port is on the wire. A tunnel also has a Tunnel role — dial out or wait — and a PSK password that encrypts the contents; it must match on both sides.
- Receive buffer (ms) — the same recovery budget in meaning as SRT's latency; 1000 by default. Next to it are Reorder section (ms), Retry count and the Multicast interface for receiving a group.
Applying changes¶
Changing the address, the port, the key or the identifier restarts the source. Changing the timeouts alone is applied on the fly.
What next¶
- Send the signal onwards over SRT — to a fixed destination or for a partner to pull.
- Add a backup input — SRT paired with a multicast.
- Input errors — how to tell a dead source from a degrading link.