RTMP vs RTSP vs SRT: Choosing a Contribution Protocol
The protocols that carry video into your pipeline rather than out of it, and why the trade-offs are completely different from HLS and DASH.
There are two halves to a video pipeline and they have almost nothing in common. The distribution half (getting video from your origin to thousands of viewers) is where HLS and DASH live, and it optimises for scale and cacheability. The contribution half gets video from a camera or encoder into your pipeline in the first place, usually as a single stream to a single destination, and it optimises for latency and reliability instead.
Using a distribution protocol for contribution is a common early mistake. Segmented HTTP delivery adds seconds of latency by design, which is fine for viewers and unacceptable for an ingest link where every second compounds through the rest of the chain.
RTMP
RTMP was built by Macromedia for Flash Player, and by rights it should have died with Flash in 2020. It did not, because by then every encoder and every ingest endpoint spoke it, and that installed base turned out to be more durable than the technology it was built for.
It runs over TCP, usually on port 1935, and multiplexes audio, video, and metadata into interleaved chunks over a persistent connection. Latency in the one-to-three-second range is typical over a decent network.
Its strengths are entirely practical. Every streaming platform accepts RTMP ingest. Every hardware and software encoder emits it. It passes through most firewalls without argument. If you need something to work with an unknown encoder operated by someone you cannot talk to, RTMP is the safe default.
Its weaknesses are structural:
• TCP-only. Packet loss triggers retransmission and head-of-line blocking. On a lossy link (cellular, satellite, congested venue Wi-Fi) RTMP degrades into stalling rather than gracefully losing quality.
• Codec limits. The specification predates modern codecs. H.264 and AAC work universally; HEVC and AV1 depend on vendor-specific extensions with inconsistent support.
• No native encryption. RTMPS wraps it in TLS, which works, but it was bolted on rather than designed in.
• Effectively unmaintained. The spec has not meaningfully evolved in over a decade.
RTSP
RTSP is a different kind of thing, and the most common confusion about it is treating it as a transport protocol. It is not. It is a control protocol. RTSP carries commands: DESCRIBE, SETUP, PLAY, PAUSE, TEARDOWN. The media itself travels over RTP, usually on separate UDP ports negotiated during setup.
That separation is why RTSP is described as working like a remote control for a media server rather than a pipe for media.
Because RTP typically runs over UDP, RTSP can achieve very low latency (sub-second is normal) since there is no retransmission or ordering guarantee to wait on. Lost packets are simply lost, producing a brief visual artifact rather than a stall. For a security camera, that is exactly the right trade.
Where RTSP struggles is anywhere with a NAT or a firewall between the endpoints. Negotiating dynamic UDP ports across consumer network equipment is unreliable, and the usual workaround (RTSP interleaved over TCP) surrenders most of the latency advantage that motivated the choice.
This is why RTSP dominates IP cameras and local surveillance systems, where both ends sit on a controlled network, and is almost absent from internet-facing contribution.
SRT
SRT (Secure Reliable Transport) was developed by Haivision and released as open source in 2017, specifically to solve the problem RTMP handles badly: moving video reliably across an unreliable public network.
It runs over UDP but implements its own selective retransmission on top. When a packet goes missing, the receiver requests just that packet, and the sender resends it, provided it can arrive within the configured latency window. That window is the central parameter of the protocol.
SRT asks you to declare how much latency you will accept, typically somewhere between 120 and 2,000 milliseconds. The receiver holds a buffer of that duration, giving lost packets time to be requested and re-delivered before their playout deadline.
The trade is explicit and tunable. A larger buffer absorbs worse network conditions at the cost of delay. The standard rule of thumb is to set the buffer to roughly three to four times the measured round-trip time. On a 30 ms RTT link, a 120 ms buffer is reasonable; over a satellite hop with 600 ms RTT, you need far more.
This explicitness is the point. RTMP's behaviour under loss is whatever TCP decides to do. SRT lets you state the constraint and engineers around it.
• AES encryption is built in, 128- or 256-bit, not a separate layer.
• Codec agnostic. SRT carries an MPEG-TS payload and does not care what is inside it, so HEVC and AV1 work without protocol changes.
• Firewall traversal via caller, listener, or rendezvous modes. Rendezvous lets both endpoints sit behind NAT.
• Bonding, in later versions, allowing multiple network paths to be combined or used as failover.
The cost is adoption. Support is now broad among professional encoders and cloud ingest services, but it is not the universal default RTMP is, and consumer-grade software support remains patchier.
Comparison
Picking One
RTMP when compatibility is the binding constraint: third-party encoders, platform ingest endpoints you do not control, or anything where the other end is unknown. On a stable wired connection it performs perfectly well.
RTSP for IP cameras and local network video. It is what the devices speak, and on a LAN its weaknesses do not apply.
SRT for anything crossing the public internet where reliability matters: remote contribution, cellular or bonded links, inter-site transport between facilities. If you have ever watched an RTMP feed stall repeatedly from a venue with poor connectivity, this is the protocol that fixes it.
A common production architecture uses SRT for the long unreliable hop from the field to a cloud ingest point, then hands off to RTMP or direct packaging for the short reliable hop into the transcoding pipeline. There is no requirement to use one protocol end to end, and there is usually no reason to.
Once video is inside the pipeline and transcoded into an ABR ladder, the contribution protocol has done its job and HLS or DASH takes over for delivery.