SRT vs RTMP — Protocol Comparison for Live Broadcast

Push a stream down a link that drops a couple of percent of its packets and you learn the difference between SRT and RTMP faster than any datasheet will teach you. The RTMP feed stutters, buffers, and eventually the audio drifts away from the picture. The SRT feed, tuned right, just keeps playing. That one experiment is why srt vs rtmp comes up in almost every contribution and distribution planning meeting now — and why the answer is rarely as tidy as one protocol being dead and the other being king.

Both protocols move live video and audio. They were built in different eras, for different networks, with different assumptions baked in. Knowing which of those assumptions apply to your particular link is the whole game. Here is the version I would give a colleague, without the marketing gloss.

What is RTMP?

RTMP — the Real-Time Messaging Protocol — was created by Macromedia and inherited by Adobe, designed in the early 2000s to stream audio, video and data between a Flash Player and a server. Flash has been gone for years; RTMP outlived it. The protocol runs over TCP, usually on port 1935, and it was the connective tissue of live streaming for the better part of fifteen years.

The specification is, for practical purposes, frozen. Adobe published it and then largely walked away, which pinned RTMP to the codecs of its day: H.264 for video and AAC for audio. A community effort called Enhanced RTMP has been retrofitting modern codecs such as HEVC and AV1, and the big ingest platforms are adopting it unevenly — but the RTMP you will meet in most tools is still the Flash-era one. There is also RTMPS, which is simply RTMP wrapped in TLS, so it is fair to say RTMP can be encrypted, even if in the field it usually is not.

Where RTMP still earns its place

It would be a mistake to write RTMP off. It is genuinely entrenched, and for good reasons.

• Every tool speaks it. OBS, vMix, Wirecast, FFmpeg, and hardware encoders from every vendor emit RTMP, and setup is a URL plus a stream key. Nothing in this business is easier to get working.
• It is still the common last hop. The major streaming platforms and plenty of CDNs accept RTMP ingest. When a feed's final destination is a public platform, RTMP is frequently the path of least resistance — sometimes the only path on offer.
• On a clean network it is fine. Over a stable LAN, or a solid last-mile connection into a nearby CDN edge, TCP's retransmissions are cheap and RTMP delivers perfectly watchable video at a couple of seconds of latency.

The trouble starts when the network stops being clean — which, on the public internet, is most of the time.

What is SRT?

SRT — Secure Reliable Transport — was built for exactly the network RTMP struggles on: the open, unpredictable public internet. Haivision created it and open-sourced the reference library in 2017, then co-founded the SRT Alliance to steward it as an industry standard. Adoption since has been quick and broad.

SRT runs over UDP and layers its own reliability on top. Rather than guaranteeing delivery at any cost the way TCP does, it recovers what it can within a fixed time budget and then moves on. A handful of design choices carry the protocol: ARQ retransmission of only the packets that actually went missing; a configurable latency buffer (a common starting point is roughly 3 to 4 times the measured round-trip time); AES encryption with 128- or 256-bit keys negotiated from a shared passphrase; and caller, listener and rendezvous connection modes that make firewalls and NAT far less painful. It carries an MPEG-TS payload, so it neither knows nor cares which codec is inside.

SRT vs RTMP, head to head

Transport: TCP versus UDP + ARQ

This is the root of every other difference. RTMP sits on TCP, which was designed for correctness over speed — it will retransmit a lost segment and hold everything queued behind it until that segment arrives (classic head-of-line blocking). Ideal for a file transfer, wrong for live media. SRT sits on UDP and implements its own selective recovery, so one missing packet does not freeze the whole pipeline.

Behaviour under packet loss

Feed both protocols a link with 1 to 2 percent loss and some jitter and the contrast is stark. RTMP's TCP layer responds to loss by retransmitting and throttling its send rate; on screen that reads as buffering, then rebuffering, then lip-sync sliding off. SRT re-requests the missing packets, slots them back into order inside its latency window, and hands a clean stream to the decoder. If a packet genuinely cannot be recovered in time, SRT drops it and keeps moving rather than stalling the stream.

Security

RTMP is unencrypted by default — anything on the path can inspect the stream. RTMPS adds TLS when both ends support it, so encryption is possible but not a given. SRT builds encryption into the protocol: AES is negotiated during the handshake, and switching it on is a passphrase, not a certificate project.

Codec and container flexibility

Classic RTMP is effectively tied to H.264 and AAC. If you want HEVC, AV1 or more than stereo audio, base RTMP will not carry it, and Enhanced RTMP support is still patchy across tools. SRT is codec-agnostic because it moves an MPEG-TS container — the same feed can carry HEVC, AV1, multichannel audio, SCTE-35 markers and multiple programs, and the transport is indifferent to all of it.

Latency

This one deserves nuance, because RTMP gets blamed for delay it does not always cause. On a good network RTMP delivers a couple of seconds of latency, and much of the lag people attribute to it is actually buffering added downstream at the CDN. What RTMP cannot give you is a predictable latency floor on a lossy link — TCP will trade latency for delivery every single time. SRT's latency, by contrast, is a number you choose: set the buffer, and within that budget the delay is deterministic. On a marginal link SRT is usually both lower and, more importantly, more stable.

Firewalls and NAT

RTMP over TCP 1935 regularly collides with corporate firewalls and needs an inbound port opened somewhere — a real headache at a venue you do not control. SRT's rendezvous mode lets both endpoints reach out at once to punch through NAT, and its caller/listener roles give you options when only one side can accept a connection.

So which should you use?

The useful framing is not which protocol wins outright but where in the chain you are standing. For the final hop into a public platform or a CDN edge that only speaks RTMP, use RTMP — it is universal and it works. For getting a signal across the open internet intact — venue to studio, studio to cloud, cloud to a downstream partner — SRT is the protocol built for the job. Plenty of real workflows run both: SRT for the hard middle miles, RTMP for the last-mile handoff to a platform that demands it.

Where SRT Cloud fits

SRT solves the transport problem. It does not, by itself, solve the distribution problem — the grind of taking one clean feed and handing identical copies to a dozen downstream destinations, each of them a connection to configure, tune and monitor, and something to restart when a link flaps at 2 a.m.

That is the job SRT Cloud was built for. 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, affiliate, CDN or satellite operator. There is no transcoding and no re-encoding, so every output is frame-for-frame identical to your source. Takers on the platform today include FreeSat, Pyur, Eutelsat, SES, Etisalat, Swisscom, UIG and KiwiSat.

Because it is a managed service, there is no hardware to rack and no media server to babysit, and the pricing is simply €99 per output per month — one license, one output — after a free trial, scaling up or down whenever a partner comes or goes. If your feed starts life as RTMP, convert it to SRT at your encoder, point that one SRT input at SRT Cloud, and let the copy machine handle the fan-out.