What Is SRT? Secure Reliable Transport for Live Video

SRT (Secure Reliable Transport) is an open-source, UDP-based protocol for moving live video across unpredictable networks at low latency. The SRT protocol recovers lost packets with selective retransmission inside a fixed latency window, 120 ms by default, and encrypts the payload with AES at 128, 192 or 256 bits. That combination makes it the standard replacement for RTMP in long-distance contribution feeds.

How the SRT Protocol Works: Retransmission Inside a Latency Budget

Secure Reliable Transport (SRT) was open-sourced by Haivision in 2017 and descends from UDT, a UDP data-transfer protocol built for high bandwidth-delay paths. A typical 2026 deployment sets receiver latency to 3–4 times the round-trip time, so a 150 ms transatlantic link runs at roughly 450–600 ms of buffer and absorbs several percent packet loss without visible artifacts.

The mechanics run on four pieces of per-connection state:

• Sequence numbers and NAK-based ARQ. The receiver detects gaps and sends negative acknowledgements immediately, plus periodic loss reports. The sender retransmits only the missing packets, not the whole window as TCP would after a timeout.
• Timestamp-based packet delivery (TSBPD). Every packet carries a sender timestamp. The receiver releases each packet to the application exactly at its timestamp plus the configured latency, which recreates the original pacing and removes jitter.
• Too-late packet drop. If a retransmission has not arrived when its release time passes, SRT discards the packet and moves on. Timing beats completeness, which suits live video.
• Bandwidth overhead cap. Retransmissions are limited to a share above the input rate, 25% by default, so a recovery burst cannot saturate the link.

Encryption keys are derived from a shared passphrase (10–79 characters) and exchanged in the handshake. Connections run in caller, listener or rendezvous mode; rendezvous lets two firewalled endpoints connect outbound simultaneously. A stream ID field lets one listener port route many feeds.

Where SRT streaming sits in the video stack

SRT is transport only. It usually carries MPEG-TS in 1316-byte payloads (seven 188-byte TS packets), which is codec-agnostic: H.264, HEVC, AV1 and multichannel audio all ride unchanged. It lives on the contribution leg, encoder to cloud ingest or venue to master control. Viewers almost never receive SRT; the packager converts the feed into HLS or DASH segments for delivery.

Worked Example: Sizing an SRT Link

Take an 8 Mbps HEVC feed from a stadium to a cloud encoder, 180 ms RTT, 2–4% loss on a bonded cellular uplink. The parameters below capture the practical tuning. They are the same options exposed by the reference library, ffmpeg and GStreamer.

The single most important setting is latency: leaving the 120 ms default on a 180 ms RTT path means lost packets can never be recovered in time, so every loss becomes a visible drop.

SRT vs. RTMP, RIST and WebRTC

SRT vs. RTMP: RTMP runs over TCP, so one lost segment stalls everything behind it, and TCP throughput falls roughly with RTT times the square root of loss. At 150 ms and 1% loss, a single RTMP connection struggles to hold high-bitrate video. SRT adds encryption natively, while RTMP needs RTMPS for that.

SRT vs. RIST: Reliable Internet Stream Transport solves the same problem with RTP-based ARQ and is specified by a broadcast industry forum rather than a single library. Choose based on encoder, decoder and cloud ingest support; interoperability matters more than protocol elegance here.

SRT vs. WebRTC: WebRTC targets sub-500 ms interactive delivery to browsers with congestion control that degrades quality to keep up. SRT holds bitrate constant and trades delay for fidelity, the right call for a feed that will be re-encoded downstream.

Common Misconceptions About Secure Reliable Transport

"SRT guarantees delivery." It does not. Packets that miss their release time are dropped by design; loss above what the latency and overhead budget can absorb still shows up on screen.

"The latency setting equals glass-to-glass delay." It is only the receiver buffer. Encode, decode and packaging delay stack on top, often adding one to several seconds.

"SRT has congestion control like TCP." Live mode deliberately does not back off. On a link without headroom, SRT keeps sending and loss climbs, so provision the uplink for peak rate plus overhead.

FAQ: What Is SRT Streaming

Is SRT better than RTMP for live streaming?

For contribution over long or lossy paths, yes. SRT recovers lost packets within a fixed latency window and encrypts by default, while RTMP over TCP suffers head-of-line blocking as RTT and loss grow. On a clean, short link RTMP still works fine, and some older platforms accept only RTMP ingest.

What latency should I set for SRT?

Start at 3–4 times the measured round-trip time, with 120 ms as the protocol default floor. Lossy paths such as cellular or satellite may need 5–6 times RTT. Watch the receiver's dropped-packet counter; if it climbs above zero during normal operation, raise latency before adding bandwidth overhead.

Does SRT work behind firewalls and NAT?

Usually yes. The caller side only needs outbound UDP, and rendezvous mode lets two NATed endpoints connect by calling each other simultaneously. The listener side needs one open UDP port. Corporate networks that block all outbound UDP will prevent SRT entirely, which is a common failure at venues.

Can viewers watch an SRT stream directly?

Rarely at scale. SRT is point-to-point contribution transport without browser support, so feeds are transcoded and packaged into HLS or DASH for playback. Media players such as VLC can open SRT for monitoring, which is useful for confidence checks but not for large audiences.

Measure Your Link Before You Tune It

This week, run your next contribution feed with SRT statistics logging enabled on the receiver. Record RTT, packets lost, packets retransmitted and packets dropped over a full event. If dropped is non-zero while retransmitted is healthy, your latency is too low; if retransmitted regularly hits the overhead ceiling, your uplink lacks headroom. Set latency from measured RTT, not the default, and rerun. For related transport and delivery explainers, browse the live streaming protocol guides on the BlazingCDN engineering blog.