SRT vs RTMP: which should you stream with?

RTMP is the older of the two and it is everywhere. Nearly every platform gives you an RTMP address and a stream key, and nearly every streaming app, camera and transmitter/encoder can send to one. If you have ever pasted a stream key into OBS, you have used it.

On a steady connection it does the job with no settings to get wrong. That is most streams from a desk, and there is no reason to change them.

RTMP runs over a kind of connection that insists on delivering everything, in order. When a packet is lost, everything behind it waits until that packet has been sent again and has arrived. On a wired line losses are rare, so you never notice.

On a mobile network they are constant. Each one holds up the queue, the delay builds, and the stream stutters, falls behind or drops. The connection is doing exactly what it was designed to do. It was not designed for live video over a network that loses packets all day.

SRT was built for video over unreliable networks. It sends without waiting for each packet to be confirmed, keeps a short buffer at the receiving end, and asks again only for the packets that went missing. If a missing packet arrives inside the buffer’s window, it is slotted back into place and nobody sees a thing. If it does not, SRT moves on instead of holding up everything behind it.

A lost packet costs you, at worst, a brief blemish, never a growing delay. On a connection that loses packets, that is the difference between a stream that holds and one that falls over.

The size of that buffer is the latency setting, and it is a trade. A bigger window gives lost packets more time to be recovered, so the stream is steadier. It also puts you that much further behind real time.

A common starting point is around four times the round trip between you and the receiver, and more on a poor network. Wired links can run on a fraction of a second. Mobile networks usually want a second or two. Your Lumbus studio shows the value to use beside its address, so there is nothing to work out.

One trap: devices count SRT latency in milliseconds, so two seconds is 2000. Command-line tools often want microseconds, where the same two seconds is 2000000.

An SRT connection has a caller and a listener. The listener waits at a known address and the caller dials in. Out in the field you are the caller: your phone or transmitter/encoder dials your studio’s address. If a device asks which mode to use for an SRT destination, the answer is caller.

SRTLA is SRT with the connections added up. Each connection carries part of the stream and the receiving end puts it back together. It is how open bonding rigs, including bonding apps on a phone, send one feed over several networks at once.

Most platforms take RTMP, and whether one accepts SRT depends on the platform and sometimes on the account, so check its ingest settings before you count on it. That is why streams on the move usually run in two legs: SRT from you to a studio or server on a solid connection, then RTMP from there to the platform.

It is how Lumbus Studio works. You send one feed, by SRT, RTMP or bonded SRTLA, and the studio sends your programme on to your platforms. Your shaky connection only has to reach the studio. The studio’s connection to each platform is the solid one, and it stays up while yours comes and goes.