RTMP vs SRT vs SRTLA for IRL streaming

All three protocols are included in every plan with a stream key. You pick one in the dashboard, copy the publish URL and that’s it: the key, the region and the playback URL stay where they were.

At a glance

	RTMP	SRT	SRTLA
Handles a bad network	Badly	Well	Best there is
Latency	The most direct one if the network holds	Whatever you set	Whatever you set
Adds up several connections (bonding)	No	No	Yes
Typical encoders	Almost all of them	Moblin, Larix, IRL Pro, your OBS	Moblin, BELABOX

RTMP

The most compatible one: every encoder and every platform speaks it. In exchange, it’s the worst at handling packet loss: the moment the network wobbles, the upload chokes and the bitrate collapses. Its publish URL is a single line that already carries your key at the end, and the playback URL is the same one.

Pick it if you broadcast from a fixed spot on a wired connection, or if your encoder supports nothing else.

SRT

Built for networks that drop packets: it resends what gets lost within a time buffer that you choose. More buffer = more room to recover, more delay on screen. The publish URL carries your key inside a streamid with the publish: prefix.

Pick it if you broadcast from your phone on a single connection, or from a network that isn’t yours (hotel, event, restaurant).

SRTLA

It’s SRT spread across several connections at once: two SIMs, a SIM and wifi, two modems. The receiver puts them back together, so if one drops the stream carries on with the others. Its publish URL starts with srtla://. Playback for an SRTLA key goes over SRT, same as all the others.

Pick it if you move around and carry more than one connection. On a single connection, SRTLA gives you nothing that SRT doesn’t.

What actually happens when packets get lost

This is the whole difference between the three, and it’s worth understanding once:

RTMP runs over a connection that insists every byte arrives in order. Lose packets and everything behind them waits. The upload stalls, the buffer fills, and your bitrate collapses — and it stays collapsed for a while after the network has already recovered.
SRT sends packets that can be re-requested individually, inside a time window you choose. A lost packet gets asked for again and arrives late but in time, and nothing behind it stops. Once the window closes, that packet is given up on rather than blocking the stream.
SRTLA does the same thing, but spread over several links at once. If one of them dies the others carry the whole load, so what would have been a disconnection turns into a drop in quality.

That’s why RTMP feels fine at home and falls apart on the street: it isn’t worse at streaming, it’s worse at losing packets. And a mobile connection loses packets constantly.

What to pick for your case

Your situation	Protocol	Why
Phone, walking down the street, one SIM	SRT	Recovers what gets lost without needing perfect coverage
Phone or backpack with two SIMs (or SIM + wifi)	SRTLA	Adds the connections up and survives one of them dropping
PC at home on a wired connection	RTMP	Stable network, zero setup, the most direct route
PC at home on weak wifi	SRT	The buffer covers the wifi micro-cuts
Encoder or camera that only speaks RTMP	RTMP	It’s all it supports

Changing protocol

You change it on the fly, without rotating the key:

Go to Stream Keys.
On the key, open the Protocol selector and pick RTMP, SRT or SRTLA.
Copy the new URL with Publish and paste it into your encoder.

Next step

What the publish URL is — how to read it and where to copy it from.
Broadcasting with Moblin — the shortest path if you go live from your phone.
My feed isn’t arriving — if you already changed protocol and it’s still blank.
How to start streaming IRL — where this decision sits among the others.