Understand SRT.
Packet by packet.

SRT stands for Secure Reliable Transport. It carries data over UDP and adds mechanisms for loss recovery, timing and optional encryption. In the illustrated video workflow, an encoder creates the compressed media stream, SRT transports it and a decoder handles playback. SRT is a transport protocol, not a video codec.

Broadcast mode sends the same data over multiple connections. The receiver uses copies that arrive in time and discards duplicates. Main/backup instead uses an active path with a fallback connection. This can protect a stream against individual path failures, but requires compatible, group-aware endpoints.

Automatic Repeat Request uses sequence numbers, feedback and a send buffer. When a receiver detects a gap, it can report the missing sequence numbers in a negative acknowledgement (NAK). The sender retransmits the buffered packets. Positive acknowledgements (ACKs) can confirm receipt of multiple packets together.

Forward Error Correction sends additional repair data proactively. In the XOR example, P is calculated from D1, D2, D3 and D4. If only D2 is missing, P and the other three data packets can reconstruct it. This repair needs no retransmission round trip, but consumes bandwidth and time for the repair group even before loss occurs.

Timestamp-Based Packet Delivery compensates for uneven arrival times. The receiver maps sender timestamps to its own clock and schedules delivery using the negotiated latency. Early packets wait in the receive buffer; delayed or repaired packets still have a chance to fill gaps within that window.

The passphrase is not directly the encryption key for every media packet. A Key Encrypting Key (KEK), derived from the passphrase and salt, protects a random Stream Encrypting Key (SEK). AES-CTR uses this stream key with packet-specific counters to generate a keystream. XOR with the media data produces ciphertext; the same operation recovers the payload at the receiver.

Galois/Counter Mode adds an authentication tag to encryption. The illustrated processing uses the stream key, a packet-specific nonce and header data as Additional Authenticated Data (AAD). The receiver checks the tag before releasing the payload. Modified or otherwise unverifiable data is rejected.

The packet filter framework operates inside SRT endpoints. A filter can process packets and generate additional filter packets. On the receiving side, it processes that information before data reaches the receive buffer. The built-in FEC filter is a concrete example: it adds repair packets and can reconstruct missing original data.

The caller starts with an INDUCTION probe. The listener responds with its HSv5 support and a SYN cookie. The caller then sends a CONCLUSION containing the cookie and the HSREQ extension; the listener responds with HSRSP. Extensions can carry capabilities, delays, keying material, Stream ID and filter configuration.

Message mode preserves application messages as separate units. If ABC and DEF are sent as two messages, they are received separately. Stream mode preserves byte order, not write boundaries. A receiver might read AB, CD and EF; the application must add its own framing if message boundaries matter.

The caller sets SRTO_STREAMID before connecting. The listener application receives this information during the handshake and decides which resource and access policy apply. In “#!::r=studioA,m=publish,u=alice”, r identifies the resource, m the requested action and u a claimed user name. This structured notation is a convention, not a mandatory format for every service.

The SRT library maintains event counters, timing estimates and buffer measurements for each socket. An application samples them with srt_bstats and builds logs, charts or alerts. Cumulative values cover the socket lifetime, interval values cover the period since the last clear, and instantaneous values describe the current state or estimate.