Getting a live feed back from a shoot, a remote studio or a guest’s home no longer has to go through a satellite or a dedicated line: most of the time, the stream travels over the internet, and two protocols share the ground, RTMP and SRT. You find them in hardware encoders, in production software, in bonded-cellular contribution units. Choosing one over the other is not just a checkbox: it decides how robust your link is, how much delay reaches air and, for anyone handling sound, the quality and sync of the audio. Let us sort it out.
RTMP: the streaming veteran
RTMP (Real-Time Messaging Protocol) was born in the Flash era, in the late 2000s. Designed to carry audio and video over the internet, it became the universal entry format for the big platforms: for years, “streaming” meant pushing an RTMP feed to a broadcast service’s ingest. It remains the lowest common denominator today: just about every encoder can send RTMP, and just about every platform can receive it.
Technically, RTMP relies on TCP, the transport protocol that guarantees every packet arrives, in order, retransmitting whatever gets lost. On a clean, stable network, that is perfect. The trouble starts the moment the link degrades: on an unstable connection, TCP retransmissions inflate latency, the stream buffers, then freezes. RTMP has no mechanism designed to absorb the losses of a flaky network; it simply suffers them. On the format side, it is also ageing: it stays confined to older codecs such as H.264 for video and AAC for audio, with no path to newer ones.
SRT: contribution built for an imperfect internet
SRT (Secure Reliable Transport) is far more recent and answers precisely what RTMP cannot do: carry a broadcast-quality live feed over a network you do not control, 4G/5G included. It runs on UDP, but adds an intelligent reliability layer on top. Rather than blindly retransmitting everything like TCP, it selectively recovers lost packets within a defined time window, and gives up on those that would arrive too late to be useful anyway.
The heart of SRT is an adjustable buffer latency. The operator sets a delay budget, typically a few hundred milliseconds. Within that window, SRT has time to request and reinsert missing packets, smoothing out network loss and jitter. So you trade a little delay for a lot of robustness: a feed that would have frozen under RTMP holds up under SRT, at the cost of a controlled, chosen latency. SRT is also codec-agnostic (it carries whatever you feed it, including modern codecs) and encrypts the stream natively, a plus for contributing sensitive content.
The table that sums it up
| Criterion | RTMP | SRT |
|---|---|---|
| Transport | TCP (full retransmission) | UDP + selective reliability |
| Behaviour on unstable networks | buffers then freezes | absorbs loss and jitter within the latency window |
| Latency | low on a clean network, unpredictable otherwise | adjustable and stable (chosen budget) |
| Codecs | fixed (H.264 / AAC) | agnostic, modern codecs possible |
| Encryption | not native | native (AES) |
| Platform compatibility | universal for final delivery | mostly for contribution, less for consumer delivery |
Which one for which job?
The two do not really compete: they often occupy two different links of the same chain.
- Contribution, field uplink, remote guest link over 4G/5G: SRT, without hesitation. This is exactly the scenario it was built for, where the network is uncertain and stability comes first.
- Final delivery to a consumer platform: RTMP is often still the required entry point, because it is what the platform accepts. Many workflows therefore contribute over SRT up to a reliable production point, then push out over RTMP to the platform.
- Point-to-point link between two control rooms: SRT, for its robustness and encryption.
For anyone working on the sound, two points deserve attention. First, latency: a generous SRT budget boosts reliability but adds delay, which complicates a live exchange between a studio and a remote guest. It is the same trade-off as for any remote feed, and the logic of audio-video over IP applies here. Second, lip sync and hitting your loudness targets at the output, which remain your responsibility whatever the transport protocol. SRT and RTMP only carry an already-encoded feed: they replace neither a good mix-minus for the guest, nor a clean contribution chain.
And compared with other transports?
SRT and RTMP live on the public internet and target remote contribution and streaming. They do not play in the same league as the internal transports of a facility: a studio’s contribution codecs and IP links, built for a controlled LAN and tiny latency, or the studio-to-transmitter link that connects the control room to the transmitter. Each to its own ground: you do not contribute a remote feed over a studio bus, and you do not wire a studio over SRT. Likewise, to carry a low-bitrate coded radio programme, you stay on dedicated chains and specialised codecs. SRT and RTMP are the tools of internet uplink and delivery, no more, no less.
My take
For contribution, the match is settled: SRT does what RTMP cannot, hold a live feed on a network that moves. That latency setting you choose yourself is a game-changer when you uplink a shoot over 5G, far from the satellite and its cost. RTMP is not dead for all that: it remains the platforms’ entry door, the last required link. So the right reflex is not to pick a side, but to know which goes where in the chain. And never to forget that the protocol carries the sound without ever caring for it: that part stays your job, upstream.
