SRT
UDP made reliable for live video: retransmit what is lost, but only in time.
A data packet
Sixteen bytes in front of the video: order, timing and flags.
Whole frame
A 16-byte header on top of UDP: a packet sequence number to detect loss, a timestamp to schedule delivery, and a socket ID. Together they turn UDP into a reliable, low-latency link.
| Field | Offset | Example value | Meaning |
|---|---|---|---|
| F (control flag) | Byte 0, bit 7 | 0 = data | 0 = data packet, 1 = control packet (handshake, ACK, NAK, keep-alive...). The very first bit decides how the rest is read. |
| Packet sequence number | Bytes 0–3 | 6699 | Counts packets (not bytes). The receiver notices a gap, asks for the missing numbers with a NAK, and the sender retransmits them: that is SRT's loss recovery. |
| PP (position) | Byte 4, bits 7–6 | 11 = solo | Where this packet sits in a message: 10 first, 00 middle, 01 last, 11 solo (the whole message in one packet). |
| O (in order) | Byte 4, bit 5 | 0 | 1 = the message must be delivered in order. Live mode sets 0 and relies on timestamps. |
| KK (key) | Byte 4, bits 4–3 | 00 = clear | Encryption: 00 = not encrypted, 01 = even key, 10 = odd key. SRT can encrypt payloads with AES. |
| R (retransmitted) | Byte 4, bit 2 | 0 = original | 1 on a packet that is being sent again after a NAK. Lets the receiver measure how much repair traffic it needs. |
| Message number | Bytes 4–7 | 1 | Identifies the message; in live streaming each packet is its own message. |
| Timestamp | Byte 8–11 | 1,000,000 µs = 1.000 s | Microseconds since the connection started, set by the sender when it first sent the packet. The receiver delays delivery to a fixed latency after this time, which absorbs jitter and leaves room for retransmissions. |
| Destination socket ID | Byte 12–15 | 0x1A2B3C4D | Agreed in the handshake: which SRT connection on the receiving end this belongs to. It lets many SRT connections share one UDP port. |
| Payload (start) | Byte 16–19 | 47 40 11 10 ... | Usually 7 MPEG-TS packets (1,316 bytes) so the whole SRT packet fits an Ethernet frame. 0x47 is the TS sync byte. |
Overview
SRT (Secure Reliable Transport) sends live video over the open internet. It runs on UDP and adds just enough: sequence numbers and NAKs to retransmit lost packets, a timestamp-based latency buffer that makes the repair arrive before playback needs it, and AES encryption.
TCP would also be reliable, but one lost packet stalls everything behind it for a round trip or more. SRT retransmits only what is missing and drops what is too late, which keeps latency low and predictable.
Key facts
- Transport
- UDP
- Header
- 16 bytes
- Loss recovery
- NAK-based ARQ within the latency window
- Encryption
- AES-128/192/256
- Typical latency
- ~4 × round-trip time (e.g. 120–500 ms)
- Standard
- IETF draft (SRT Alliance)
The handshake
How two ends agree on a connection over UDP.
Whole exchange
Four UDP packets set up a connection: a cheap knock, a cookie, the settings, the confirmation. SRT adds the connection that UDP lacks without a TCP handshake's retransmission delays.
11. Caller knocks
The first handshake packet, sent as a control packet over UDP. It is deliberately minimal and carries no secrets, so a listener can answer without remembering anything about the caller.
22. Listener answers with a cookie
The reply upgrades to handshake version 5 with the SRT magic 0x4A17 and a cookie derived from the caller's address. This works like TCP's SYN cookies: it proves the caller really is at that address, so spoofed requests cost the listener nothing.
33. Caller concludes with its settings
The caller echoes the cookie and adds its extensions: SRT version, the latency it wants (say 120 ms), encryption key material if used, and optionally a stream ID saying which stream it wants.
44. Listener confirms: connected
The listener returns its socket ID and the latency it agreed (the larger of both sides' requests). Data packets can now flow, addressed to those socket IDs.
Recovering a lost packet
Loss, NAK, retransmission, all before the deadline.
Whole exchange
SRT repairs loss only if the repair arrives before the deadline. The latency setting is the trade-off: more latency, more chances to retransmit; less latency, more risk of glitches.
1Packet 100 arrives
Each packet is stamped with a timestamp and held by the receiver until timestamp + latency, then released to the decoder at a smooth pace.
2Packet 101 is lost
The network drops it. Plain UDP would simply have a hole in the video.
3Packet 102 reveals the gap
102 arrives right after 100. The receiver now knows 101 is missing, long before its playout deadline.
4The receiver asks again
A NAK (negative acknowledgement) names exactly the missing sequence numbers. Unlike TCP, nothing else is held back: later packets keep arriving.
5Retransmission in time
The sender resends 101 with the R flag set. It arrives before 101's delivery time because the configured latency (typically a few round-trip times) leaves room for it. The video plays without a glitch.
6Periodic ACK
Every 10 ms the receiver reports the highest sequence number up to which everything arrived, so the sender can free its retransmission buffer.
Where you meet it
- Remote production and contribution: sending a camera feed to a studio over the internet
- Live streaming encoders (OBS, vMix, hardware encoders) and servers (FFmpeg, Wowza)
- Replacement for RTMP and for legacy satellite links
Watch out for
- If the latency setting is smaller than a couple of round-trip times, retransmissions arrive too late and the stream glitches even though SRT 'is reliable'.
- Caller/listener roles are about who initiates the connection, not who sends video. The listener can be the sender, which helps with firewalls.
- The passphrase must match on both ends, otherwise the connection is rejected rather than showing garbage.
Standards
- draft-sharabayko-srt (The SRT Protocol), IETF
- SRT Alliance