SRT (Secure Reliable Transport) is an open-source transport protocol that delivers live video over the public internet with low latency, packet-loss recovery and encryption. In streaming and broadcasting, it is used mainly for contribution links: moving a high-quality feed from a camera, encoder or venue to a production center, cloud platform or broadcaster.
SRT runs on top of UDP and adds the reliability that UDP lacks through selective retransmission within a fixed latency window. It was originally developed by Haivision, released as open source in 2017 and is now supported by a wide range of encoders, decoders, media servers and cloud services.
How SRT protects a live stream
SRT works by buffering packets for a configured latency and using that time to recover losses. Every packet carries a sequence number and a timestamp. When the receiver detects a gap, it sends a negative acknowledgment (NAK) and the sender retransmits only the missing packet.
The receiver releases packets to the decoder exactly when their timestamp says so, measured from the start of the session plus the latency. This keeps the original timing of the stream intact, so jitter introduced by the network does not reach the decoder. If a packet does not arrive before its release time, SRT drops it rather than delaying the stream, a mechanism called too-late packet drop.
Security is built in. SRT can encrypt the payload with AES at 128, 192 or 256 bits, with keys derived from a shared passphrase. The protocol is payload-agnostic, although live video usually travels as an MPEG transport stream with seven 188-byte TS packets in each SRT packet.
Key SRT parameters
SRT behavior is tuned through a small set of parameters that must match the network conditions. The latency value is by far the most important one.
| Parameter | Typical value or range | What it controls |
|---|---|---|
| Latency | 120 ms default; often 3 to 4 times RTT | Time available for retransmission |
| Overhead bandwidth | 25% default | Extra capacity reserved for retransmitted packets |
| Passphrase | 10 to 79 characters | Key derivation for AES encryption |
| Key length | 128, 192 or 256 bits | Encryption strength |
| Payload size | 1316 bytes for MPEG-TS | Fit within a standard network MTU |
A common rule of thumb sets latency to at least four times the round-trip time on a clean path and higher on lossy links. Too little latency leaves no time for retransmission, so lost packets turn directly into visible macroblocking or frozen frames.
Connection modes
SRT separates who initiates the connection from the direction of the video. This allows a stream to cross firewalls and network address translation without changing which side sends the content.
| Mode | Behavior | Typical use |
|---|---|---|
| Caller | Initiates the connection to a known address and port | Field encoder calling a fixed server |
| Listener | Waits for incoming connections on a port | Cloud ingest point or decoder with a public address |
| Rendezvous | Both ends connect to each other simultaneously | Two sites behind firewalls |
Because a caller can also be the sender, a remote encoder behind a mobile router can push a stream to a listener in a data center without opening inbound ports at the venue.
How SRT compares with other streaming protocols
SRT occupies the contribution side of a streaming chain. It competes with RTMP for ingest and with dedicated broadcast links, while delivery to viewers usually relies on HTTP-based formats such as HLS and MPEG-DASH.
| Protocol | Transport | Typical latency | Main role |
|---|---|---|---|
| SRT | UDP with ARQ | Sub-second to a few seconds | Contribution over the internet |
| RTMP | TCP | A few seconds | Legacy ingest to streaming platforms |
| HLS and MPEG-DASH | HTTP over TCP | Several seconds, lower with low-latency modes | Delivery to large audiences |
| NDI | TCP or UDP on a local network | Very low | Production inside a facility |
| SDI | Coaxial or fiber cable | Near zero | Baseband within a facility |
Compared with RTMP, SRT avoids the head-of-line blocking of TCP, supports modern codecs such as HEVC and AV1 without extensions and offers native encryption. Compared with NDI, it is designed for wide-area links with unpredictable loss rather than a controlled local network.
Limitations and practical pitfalls
SRT recovers losses only within its latency budget and bandwidth headroom. When the available bandwidth falls below the stream bitrate, no retransmission scheme can help, and the encoder bitrate must be reduced.
- Latency set too low: high packet drop counters and frequent artifacts on long-distance links.
- Mismatched passphrase or key length: the connection fails during the handshake, often with a generic error.
- Bursty losses on mobile networks: may exceed what retransmission can fix; bonding several links or adding forward error correction helps.
- Firewall rules for TCP only: SRT needs the chosen UDP port open on the listener side.
- Ignoring statistics: RTT, retransmitted packets and dropped packets show link health before viewers notice problems.
A plain-language summary
SRT is a way to send live video across the internet without it falling apart. The internet often loses small pieces of data along the way. SRT keeps a short waiting period, notices which pieces are missing and quickly asks for them again before the picture needs them.
It works like a courier who waits a moment at each stop to collect any parcels that went missing. The waiting period is short enough for live use. The video also travels locked, so others on the network cannot watch it.
An example from practice
A regional broadcaster covers a city marathon with a camera crew at the finish line. Instead of booking a satellite truck, the crew connects a hardware encoder to a bonded cellular router and sends an HEVC stream at 8 Mbit/s over SRT to a listener in the station’s cloud gateway.
The measured round-trip time is about 80 ms, but cellular loss is irregular, so the engineer sets latency to 800 ms and enables AES-256 encryption with a shared passphrase. During the race, the SRT statistics show regular retransmissions but almost no dropped packets. The finish-line pictures reach the studio less than a second behind real time, ready to be cut into the live program.