Both protocols get video from an encoder into your origin; neither is what viewers receive. Judged on that one job, they differ sharply under packet loss — and the SRT latency setting decides whether it helps at all. A comparison, with the pipeline around it.
RTMP vs SRT is a contribution question, not a delivery one. Both protocols exist to get video from an encoder into your origin; neither is what your viewers receive, which is almost always HLS, LL-HLS, DASH or WebRTC. Getting that distinction straight removes most of the confusion, because the two protocols are then judged on one job: carrying a stream across an imperfect network without the picture falling apart.
RTMP (Real-Time Messaging Protocol) is a TCP-based contribution protocol: the encoder opens one ordered, reliable connection to the ingest server and pushes audio and video frames over it.
It was built by Adobe for Flash and runs over TCP, conventionally on port 1935. Flash is long gone and RTMP outlived it, because every encoder on earth speaks it. It is the lowest-friction thing you can point at a server, and for a stable path it works perfectly well.
Its limits come from TCP. Delivery is strictly ordered, so a single lost packet holds up every packet behind it until the retransmission arrives — head-of-line blocking. On a clean path this is invisible. On a lossy one, the encoder's send buffer grows, latency climbs, and eventually the encoder either stalls or starts dropping frames. Classic RTMP also carries H.264 and AAC in practice; the Enhanced RTMP specification maintained by the Veovera Software Organization extends it to HEVC, AV1, VP9 and HDR, but both ends have to implement it, so check your encoder and your server before planning around it.
SRT (Secure Reliable Transport) is a UDP-based contribution protocol with its own selective retransmission: the receiver names the packets it lost, the sender resends them, and everything happens inside a latency budget you configure.
It was developed by Haivision and open-sourced in 2017. It runs over UDP with its own retransmission scheme: the receiver asks for specific lost packets, and the sender resends them, all inside a latency budget you configure. It encrypts with AES natively. It is published as an IETF Internet-Draft rather than a ratified RFC, which matters less than it sounds given the breadth of implementations.
The design trade is explicit. SRT holds a buffer of a few hundred milliseconds so lost packets can be recovered within it, and it never blocks the stream waiting for one. You choose to spend latency to buy resilience, and you choose how much.
SRT's latency parameter is the size of that recovery window. Set it too low and retransmissions arrive after their deadline and get dropped anyway; set it absurdly high and you have added delay for nothing.
The working rule is three to four times the round-trip time of the path, with a practical floor around 80 ms because a very short window leaves no room to recover a burst:
RTT 10 ms → 3-4× = 30-40 ms → use the 80 ms floor
RTT 40 ms → 3-4× = 120-160 ms
RTT 120 ms → 3-4× = 360-480 ms
libsrt's own default is 120 ms, which is a reasonable starting point and too low for a long path. Measure the RTT to your ingest endpoint first — the one your encoder will actually use, at the hour it will actually stream. Also leave bandwidth headroom: SRT's default overhead allowance is 25% above the stream bitrate, and retransmissions need somewhere to fit. A 12 Mbps contribution feed wants roughly 15 Mbps of reliably available upstream.
| RTMP | SRT | |
|---|---|---|
| Transport | TCP | UDP with ARQ |
| Typical ingest latency | 2–5 s | under 1 s |
| Behaviour under loss | Stalls, then drops frames | Recovers within the latency window |
| Encryption | Via RTMPS (TLS) | Built in, AES |
| Codecs | H.264/AAC; more via Enhanced RTMP | Codec-agnostic, it carries a transport stream |
| Encoder support | Universal | Broad and growing |
| Firewall friendliness | Good on 443 with RTMPS | UDP is sometimes blocked |
The decision usually falls out of three questions.
Is the contribution path lossy or long? A venue on shared Wi-Fi, a bonded cellular uplink, a feed crossing an ocean — SRT, and it is not close. Recovering loss inside a bounded window is precisely the problem it was built for.
Is the encoder fixed? Hardware encoders, legacy appliances and some platforms speak RTMP and nothing else. Accept it and put the SRT hop somewhere you control, between your own ingest and your own origin.
Does the network allow UDP? Corporate and venue networks sometimes block or aggressively shape UDP. RTMPS over 443 gets through nearly everywhere. Have the fallback configured before the event, not during it.
For anything mission-critical the answer is both: an SRT listener as the primary, an RTMP endpoint as the fallback, and a rehearsal that proves the failover works.
Contribution is one hop. The full chain on a live streaming server looks like this:
encoder ──SRT/RTMP──► ingest ──► transcode (ABR ladder) ──► package ──► HLS/LL-HLS ──► viewers
Ingest and transcode are cheap in bandwidth and expensive in CPU; egress is the opposite. Streaming server requirements sizes each stage separately, which matters because a single contribution feed at 12 Mbps and an audience pulling an ABR ladder are different orders of magnitude — the arithmetic for the second is in concurrent viewers per server.
Every common ingest stack runs on a box you control. nginx-rtmp is RTMP-only and still perfectly good at it; SRS, OvenMediaEngine, MediaMTX, Nimble and Ant Media handle SRT as well, and FFmpeg speaks both ends of both protocols for testing. Full root means the choice is yours rather than your platform's.
A quick sanity test before you trust any of it, with a file standing in for the encoder:
ffmpeg -re -i test.mp4 -c copy -f mpegts \
"srt://ingest.example.com:9000?pkt_size=1316&latency=200000"
ffmpeg -re -i test.mp4 -c copy -f flv \
rtmp://ingest.example.com/live/streamkey
SRT's latency is in microseconds, which is a reliable source of wrong values — 200000 is 200 ms.
Swapping RTMP for SRT saves seconds at the contribution hop and changes nothing downstream. If viewers see 30 seconds of delay, the segments are the cause: standard HLS with six-second segments and a three-segment buffer is roughly 18 seconds before anything else is counted. LL-HLS brings that to a few seconds; WebRTC goes under one at a real cost in scale and complexity.
Budget the whole chain before optimising one hop of it. Contribution, transcode, packaging, CDN and player buffer each own a slice, and the biggest slice is almost never the protocol argument you came in with. Where the origin itself is the constraint — cache headers, range requests, how a CDN fetches from you — CDN origin server covers it.
No, and it should not be. SRT is better on lossy or long paths; RTMP is universally supported and fine on a clean one. Most production setups run an SRT primary with an RTMP fallback rather than choosing.
Flash is. RTMP is not — it remains the default ingest for major platforms and every encoder supports it. Treat it as a mature contribution protocol with a known weakness under packet loss.
Only its own hop, typically a couple of seconds. Viewer-side latency is dominated by segment length and player buffer, so use LL-HLS or WebRTC if that is the number you need to move.
Technically yes, and a few players support it, but it does not cache in HTTP infrastructure the way segmented formats do, so it scales poorly to a large audience. Use it for contribution and between your own nodes.
SRT if the source is remote or the path is imperfect, with an automatic RTMP fallback and monitoring on both. Continuous streams fail eventually; what matters is whether the failure is a reconnect or an outage. If you want the ingest and video on demand sides sized together, send us the channel count and bitrates.
Capacity is the easy half of a backup. What decides whether it is worth having is how long the restore takes, whether anyone verified the archive, and whether an attacker holding your production credentials can also delete the backups.
Kernel settings are changeable; the distance between your server and your users is physics. Work out the latency floor from the map, understand why interconnection decides how close you get to it, and test from where the users actually are before committing.
One exit node is easy to specify and tells you nothing about the next fifty. Concurrency, throughput per session and oversubscription set subscribers per node; packet rate rather than cipher choice sets the ceiling; and country coverage wants a tiered fleet, not identical boxes.