SRTLA vs SRT vs RTMP

Why this is so confusing

Nobody sets out to learn streaming protocols. You open an app, hit a dropdown, and it offers you RTMP, SRT, and SRTLA with no explanation of what any of them are or which one your setup needs.

The names do not help. SRT and SRTLA differ by two letters and do meaningfully different things. RTMP sounds modern and is over twenty years old. And most explanations online are written for broadcast engineers who already know what a latency budget is.

So here is the plain version. No prior networking knowledge assumed.

RTMP was built by Macromedia for Flash Player. Flash is long dead; RTMP outlived it for one reason: by the time anyone wanted to replace it, every encoder, every platform, and every OBS user already spoke it. Twitch, YouTube, Kick, and Facebook all still accept RTMP ingest today, even though they immediately repackage your stream into something else for viewers.

It carries H.264 video and AAC audio over a single long-lived TCP connection. That TCP part is the whole story — both why RTMP is dependable on good internet and why it is the wrong tool on a phone.

Why TCP breaks on cellular

TCP guarantees that everything arrives, in order. When a packet goes missing, TCP re-sends it and holds back every packet behind it until the gap is filled. That is called head-of-line blocking, and on a wired connection you will never notice it.

On a moving cellular connection you notice constantly. Packets drop regularly, TCP slows the sender down and buffers more, and delay quietly grows. From the outside the stream looks fine right up until it isn't — the transport hides the problem until the backlog is too big to recover from, and then the stream stalls or drops entirely.

Transport

TCP

Typical latency

2–5 seconds end to end

Encryption

None built in — RTMPS wraps it in TLS, but hardware support varies

Bonding

Not supported

Best at

Stable wired connections, and being accepted by literally everything

SRT starts from the opposite assumption to RTMP: the network is going to lose packets, so plan for it rather than pretending otherwise.

It runs over UDP, which by itself does not guarantee delivery at all. SRT adds the recovery back on its own terms. The receiver watches for gaps and asks for the specific missing packets — not everything after them. That is called selective retransmission, or ARQ, and it is the core difference from TCP: one lost packet does not hold up the queue.

The latency setting

SRT gives you a latency buffer you configure yourself, and this is the setting people get wrong. It is the time budget for recovery: how long the receiver waits for a late or re-sent packet before giving up and moving on. Set it too low and retransmissions arrive after the deadline and get thrown away, which looks like glitching and broken video. Set it high and you get more resilience at the cost of delay.

The common guidance is to make it several times your round-trip time — at least four times is a widely used rule of thumb — and to size it for your worst moments rather than your average ones.

SRT also has real encryption, using AES with a shared passphrase. If you need your contribution feed protected in transit, this matters, and it is a genuine advantage over both RTMP and what we do.

The limitation: SRT moves one stream over one connection. It handles a bad connection well. It cannot use a second one.

Transport

UDP with selective retransmission

Typical latency

Whatever you configure — often a few hundred milliseconds

Encryption

Optional AES-128 or AES-256

Bonding

Not supported — one link only

Best at

A single unreliable connection, and anywhere encryption is required

SRTLA is SRT with the one thing SRT lacks: the ability to use several connections at the same time. It came out of the BELABOX project and it is the reason bonded IRL streaming became achievable without broadcast budgets.

The idea is straightforward. Instead of one modem carrying your stream, you use several — ideally on different carriers — and the packets get distributed across all of them. A sender-side proxy splits the traffic out, and a receiver on the server side collects packets from every path and reassembles the original stream before handing it on.

The clever part is how it decides what goes where. SRTLA tracks how many packets are in flight on each link along with a window size that follows each link's capacity, in a way deliberately similar to TCP's congestion control. Traffic is then balanced dynamically as conditions change. When one carrier degrades, its share shrinks and the others pick up the slack.

Two things follow from this. Your usable bandwidth is roughly the sum of your connections. And your reliability is much better than any one of them, because a packet only has to make it through on one path.

What SRTLA does better than we do

Worth stating plainly, because it is true and you will find out anyway. SRTLA is open source and free. It is not tied to any one company, so if a vendor disappears your setup still works. It runs on hardware you can buy or build yourself, it is not limited to one operating system, and there is a large community producing guides and troubleshooting help. It inherits SRT's AES encryption. And you can point it at your own server or any of several hosts.

The trade-offs are setup complexity and tuning. Getting good results means understanding buffer settings and retransmission windows, and a misconfigured SRTLA setup can perform worse than a single plain SRT connection.

Transport

UDP — SRT with link aggregation

Typical latency

Your SRT buffer plus reordering across links; 2 seconds is a common setting

Encryption

Inherits SRT's AES

Bonding

Yes — this is the entire point

Best at

Bonding multiple modems with open, vendor-neutral tooling

Everything above this point applies whether or not you ever use our product. This section is about our own transport, so read it with that in mind.

It is built from scratch on UDP — not a wrapper around SRT — with its own loss handling, because the goal was to keep working in poor coverage without the slowdown that comes from a transport designed for a different kind of network.

Bandwidth is reported, not guessed

Each connected device reports the bandwidth it can actually sustain back to the streaming phone, and the encoder is set accordingly. If one device is managing 1 Mbps and another is managing 5, the encoder targets 6 Mbps and the data is allocated to match. When conditions change, the target changes with them.

Any link, not just cellular

Links can be phones on cellular, a Wi-Fi hotspot, or a hardwired connection. Starlink over ethernet alongside two cellular devices and a hotspot is a perfectly normal configuration. We have tested up to six simultaneous links; beyond that the practical limit is what your local network can carry, not the protocol.

Failing links are probed, not abandoned

The server measures the spacing between when packets were sent and when they arrived, evaluated across groups of twenty packets. When a link genuinely falls apart, the app keeps sending data over it while also duplicating that data across a healthy link. The stream stays intact, and because traffic is still flowing over the weak connection, the system can tell the moment it starts recovering and begin using it again — rather than writing it off and never checking back.

The buffer that hides dropouts

In good conditions the app holds only about 50 KB before sending. Under stress it will hold up to five seconds of video before it starts dropping frames, and in practice that is often long enough for some part of the connection to come back — at which point the backlog flushes and your viewers never see the freeze. The server keeps its own buffer for the same reason: links have different latencies, and it needs room to reassemble frames and request anything missing.

Those five-second figures are maximum depth under stress, not fixed delay. Normal operation runs far shallower, which is how glass-to-glass lands around half a second. Transport latency alone measures roughly 55 ms to an AWS server in North Virginia and about 75 ms self-hosted. Encoding on the phone uses Apple's VTCompressionSession in real-time mode, which adds very little.

What happens if you drop entirely

Our servers keep an outbound RTMP stream running to your platform even when your connection is gone. Viewers see a holding card rather than a black screen or an ended broadcast, and Twitch or YouTube never sees the stream stop.

Which one should you use

Streaming from a desk on wired internet

RTMP. There is no problem to solve. Everything supports it and TCP behaves itself on a stable connection.

One cellular connection, moving around

SRT. You get proper loss recovery and a latency budget you control. Bonding protocols cannot help you with only one link.

Several connections, and you want open tooling

SRTLA. Free, open, hardware-flexible, encrypted, and not dependent on any one company staying in business. Budget some time for tuning.

Several connections, iOS, and you want it to just work

Our protocol. Multiple phones and mixed link types with no separate hardware, no proxy to configure, and no buffer settings to get wrong. The cost is that you are on our relays and your media is not encrypted in transit.

Anything requiring encrypted contribution

SRT or SRTLA. Not us.

Other protocols you will see

RIST

Reliable Internet Stream Transport, an open standard from the broadcast industry solving much the same problem as SRT — recovering lost packets over unreliable IP links. It is common in professional broadcast contribution and rare in IRL streaming, mostly because the tooling grew up around broadcast equipment rather than consumer apps. If you see it in a menu and you are streaming to Twitch, it is almost certainly not what you want.

WebRTC and WHIP

WebRTC is what powers video calls in browsers, and it can go sub-second — faster than anything else here. WHIP is the piece that lets you publish a WebRTC stream to a server with a simple ingest URL. It is increasingly used for very low latency streaming, but it was designed for conversations rather than long broadcast contribution over lossy mobile links.

HLS

HLS is not a contribution protocol at all, which is the main thing to know. It is how streams get delivered to viewers: chopped into segments, served over normal web infrastructure, at 10 to 30 seconds behind live. Your viewers are almost certainly watching over HLS regardless of what you streamed in with.

Common questions

Keep reading