What Is SRT? Secure Reliable Transport, Explained

If you work anywhere near live video, you have seen the three letters everywhere — in encoder menus, on ingest URLs, in vendor datasheets. SRT stands for Secure Reliable Transport. It is an open-source transport protocol for moving low-latency video and audio across unpredictable networks, including the ordinary public internet, without the picture falling apart.

That one-line definition is the answer most people are looking for. The rest of this article is the part that actually matters if you have to make SRT work in production: what it does, how it does it, and where it fits against the protocols it replaced.

What problem does SRT solve?

For decades, getting a broadcast-grade signal from point A to point B meant satellite time, dedicated fiber, or a managed MPLS circuit. Reliable, but expensive, slow to provision, and inflexible. The obvious alternative — the public internet — was considered too hostile for live contribution. Packets get lost. Latency wanders. Jitter smears timing. A protocol like RTMP, built on TCP, reacts to any loss by retransmitting and backing off, which on a lossy link turns into buffering, rebuffering, and drift.

SRT was designed to make the public internet behave well enough for professional contribution and distribution. It gives you most of the reliability of a managed circuit at a fraction of the cost, over connections you already have. That is the whole pitch, and it is why SRT went from one vendor's idea to a de facto standard across the industry in only a few years.

Who created SRT?

SRT was created by Haivision, who open-sourced the reference library (libsrt) in 2017 under the Mozilla Public License. That same year Haivision and Wowza co-founded the SRT Alliance, an industry group that now counts hundreds of member companies. Contributors such as Softvelum have been active in the open-source project since its early days. Haivision remains the primary steward of the protocol, and their documentation is still the reference implementation everyone measures against — worth bookmarking if you plan to tune SRT seriously.

Give credit where it is due: without Haivision open-sourcing the code rather than keeping it proprietary, SRT would not have become the interoperable standard it is today.

How SRT actually works

SRT runs on top of UDP and borrows its congestion-control lineage from UDT (UDP-based Data Transfer). Where TCP guarantees delivery at the cost of latency, SRT does something smarter for real-time media: it recovers what it can within a fixed time budget and moves on. Four ideas do the heavy lifting.

ARQ error recovery

SRT uses ARQ — Automatic Repeat reQuest. The receiver tracks packet sequence numbers, notices gaps, and asks the sender to retransmit only the specific packets that went missing. Because this happens inside a bounded window, a burst of loss on a bad Wi-Fi hop or a congested peering point gets repaired before the decoder ever sees it. Unlike TCP, SRT will not stall the whole stream waiting forever for one late packet — if a packet cannot be recovered in time, it is dropped and the stream keeps moving.

A configurable latency buffer

This is the dial that separates people who understand SRT from people who fight it. SRT maintains a latency buffer — a small, deliberate delay that gives lost packets time to be re-requested and re-delivered in order. The rule of thumb: set latency as a multiple of your round-trip time (RTT). A common starting point is roughly 3–4× RTT, then adjust for measured packet loss. Too low and you lose recovery headroom; too high and you add needless delay. Get this number right and a link that looks marginal on paper carries clean pictures.

AES encryption

Security is not bolted on — it is in the name. SRT supports AES encryption with 128-, 192-, or 256-bit keys, negotiated during the handshake from a shared passphrase. Your feed is encrypted end to end across the open internet, which matters when the alternative is an unencrypted RTMP push or a raw MPEG-TS stream anyone on the path could tap.

Firewall and NAT traversal

SRT connections come in three modes: caller (initiates the connection), listener (waits for one), and rendezvous (both sides reach out at once to punch through NAT). This flexibility means you can usually establish a session without begging IT to open inbound ports at every site — a genuinely underrated feature when you are provisioning a feed from a stadium you do not control.

SRT is also codec- and container-agnostic. It typically carries an MPEG-TS payload, which means it does not care whether you are sending H.264, HEVC, AV1, or multichannel audio — it just moves the bits reliably.

SRT vs RTMP, briefly

RTMP was the workhorse of live streaming for fifteen years, and it is not dead — but it shows every one of those years. RTMP rides on TCP, was built in the Adobe Flash era, and is effectively frozen as a specification. On a clean network it is fine. On a lossy one, TCP's retransmit-and-backoff behavior turns packet loss into visible buffering, and RTMP is practically limited to H.264 and AAC.

• Transport: RTMP uses TCP; SRT uses UDP with its own recovery. UDP is the right foundation for real-time media.
• Loss handling: RTMP stalls; SRT repairs within a time budget and keeps moving.
• Security: RTMP is unencrypted by default; SRT encrypts with AES.
• Codecs: RTMP is stuck on H.264/AAC; SRT carries anything inside MPEG-TS.

SRT is not the only modern option — RIST (an open standard from the Video Services Forum) and Zixi (proprietary, with a large managed-network business) solve similar problems well. But SRT's combination of open licensing, broad vendor support, and simple operation has made it the default choice for new deployments.

Where SRT is used in broadcast

SRT shows up anywhere a professional signal has to cross a network that nobody fully controls:

• Contribution: getting a live feed from the venue back to the studio or playout centre, often in place of a satellite uplink.
• Remote production (REMI): cameras and feeds at the event, production staff back at home base.
• Backhaul and primary distribution: moving channels between facilities, data centres, and cloud regions.
• Affiliate and partner delivery: handing a clean feed to broadcasters, telcos, CDNs, and satellite operators downstream.

That last category — distribution to many downstream destinations — is exactly where operating SRT at scale gets tedious, and where SRT Cloud comes in.

How SRT Cloud uses SRT

Understanding the protocol is one thing; running it for a dozen downstream partners is another. Every destination is a connection to configure, a latency figure to tune, a session to monitor, and something to restart at 2 a.m. when a link flaps.

SRT Cloud is built for exactly that job, and its model is deliberately narrow. You send one SRT input. SRT Cloud produces unlimited bit-exact, 1:1 copies of it — and delivers each copy to a taker, a downstream B2B destination such as a broadcaster, telco, CDN, or satellite operator. There is no transcoding and no re-encoding: every output is frame-for-frame identical to your source. What you send is exactly what each taker receives.

Because it is a managed cloud service, there is no hardware to rack, no media server to babysit, and no long-term commitment. Pricing is simply €99 per output per month — one license equals one SRT output — and you scale outputs up or down whenever a partner comes or goes. You keep control of the protocol; SRT Cloud takes over the copy-and-deliver drudgery that otherwise grows linearly with every new taker.

SRT solved the transport problem. SRT Cloud solves the distribution problem sitting on top of it.