RTMP and SRT both carry your picture and sound across the internet. The difference is how they deal with a bad network. RTMP runs over TCP and waits for every packet until everything backs up. SRT runs over UDP, resends exactly the packets that were lost, and gives up after a set time instead of holding up the whole stream.
The short answer for practice: SRT for the way from you to the studio, RTMP(S) for the way to the platform.
Each has a variant. RTMPS is RTMP with encryption. SRTLA is SRT over several connections at once. Neither changes the principle, but each solves a problem of its own.
RTMP in short
RTMP is the protocol Twitch, YouTube, Kick and nearly every other platform take streams with. You enter a server address and a stream key, and it runs.
Underneath is TCP. TCP guarantees that all data arrives complete and in the right order. For a web page that is exactly right. For live video it has a catch: when a packet is lost, everything behind it waits until it has been delivered again. On a stable line at home nobody notices. On mobile data the stream backs up, the app cannot keep up with sending, and in the end the platform closes the connection. What happens then is described in Why your Twitch stream goes offline in a dead spot (in German).
RTMPS in short
RTMPS is RTMP inside an encrypted connection, the way https is an encrypted version of http. The address begins
with rtmps:// instead of rtmp://; everything else you enter is the same.
The encryption protects two things on the way: your stream key and the stream itself. With plain RTMP the stream key crosses the network readable. Somebody listening on the route, on an open Wi-Fi for example, can copy it and send on your channel with it.
RTMPS changes nothing about the behavior on a bad network. TCP is still underneath, and the backlog is the same.
If a platform offers both, take RTMPS. Some accept nothing but RTMPS by now, Kick and Facebook for example.
SRT in short
SRT stands for "Secure Reliable Transport". It is an open protocol, developed by Haivision and open source since 2017. It was built for exactly the routes RTMP struggles on: mobile data, crowded Wi-Fi, long ways across the public internet.
SRT runs over UDP. UDP guarantees nothing; it just sends packets off. SRT brings the reliability itself: the receiver notices which packet is missing and asks for exactly that one again. There is a time window for that, the latency. If the packet arrives within it, nobody notices anything. If it does not, it is skipped, and the stream goes on. How that works in detail is explained in What is SRT? (in German).
SRTLA in short
SRTLA stands for "SRT Link Aggregation" and comes from the BELABOX project. The sender spreads the packets of one SRT stream over several connections, for example two SIM cards and a Wi-Fi network. The receiver puts them back together into one stream. That is called bonding.
SRT repairs a connection that loses packets. Against a connection that fails completely it does not help. That is where SRTLA comes in: when one network fails, the stream goes on over the others.
It needs a receiver on the other side that understands SRTLA. A receiver for plain SRT cannot do anything with the packets. PGM.STUDIO does not accept SRTLA yet; bonding is planned. What works until then is in SRTLA and bonding: what your studio accepts.
The comparison
| RTMP | RTMPS | SRT | SRTLA | |
|---|---|---|---|---|
| Transport | TCP | TCP, encrypted with TLS | UDP | UDP over several connections |
| Lost packet | everything behind it waits | like RTMP | is resent on request | like SRT |
| When the resend comes too late | backlog, finally a disconnect | like RTMP | the packet is skipped, a short picture error | like SRT |
| When the connection fails completely | the stream breaks off | like RTMP | the stream breaks off, the sender connects again | goes on over the remaining connections |
| Delay | grows unchecked on a bad network | like RTMP | a fixed time window that you set | like SRT |
| Encryption | none, the stream key is readable | TLS | possible, with a passphrase | like SRT |
| Platforms as a destination | practically everywhere | practically everywhere, some require it | rarely | none, only receivers of your own |
| On restricted networks | nearly always gets through | nearly always gets through | fails when the network blocks UDP | like SRT, for each connection separately |
| Setup | server address and stream key | the same with rtmps:// |
address with port, often with a stream ID | like SRT, with srtla:// and several networks at the sender |
| Typical use | from the studio or PC to the platform | from the studio or PC to the platform | from camera, phone or encoder to the studio | from a backpack with several SIM cards to the receiver |
| In PGM.STUDIO | destinations | destinations | sources | planned |
A note on encryption: your studio accepts SRT without a passphrase; the field stays empty in the app.
Two rows deserve an explanation.
Delay. With SRT you decide how long a missing packet is waited for. That value is the latency, and it applies to the whole stream. A larger value survives worse networks and costs a little more delay. RTMP has no such control. The delay is small on a good network and grows on a bad one, and you cannot influence it.
Restricted networks. Many hotel, company and public Wi-Fi networks block or throttle UDP. Then SRT does not get through although the network works otherwise. The way out is the phone's mobile data or a hotspot. More in SRT on hotel or company Wi-Fi.
Why not SRT all the way to the platform?
Because the platforms expect RTMP(S). That is no drawback: the route from a data center to the platform is stable, and there RTMP does what it should. Only the first stretch is hard, from you to the internet. SRT was made for that stretch.
That gives the usual setup for streams from the road:
- Camera, phone or encoder send over SRT to a station in a data center.
- The station sends over RTMP(S) to the platform.
That station can be a server of your own, a relay, a rented OBS or a cloud studio. The differences are in Relay, cloud OBS or cloud studio (in German).
PGM.STUDIO works exactly this way. Your studio takes up to eight sources over SRT and sends the finished program over RTMP or RTMPS to up to eight destinations. When a source drops out, the connection to the platform stays.
When RTMP is all you need
If you stream from home over fiber or cable and send straight to a platform, you do not need SRT. The line is stable, and RTMP is easier to set up. SRT pays off as soon as one of the routes becomes uncertain: mobile data, somebody else's Wi-Fi, a camera in another place.
Summary
- From you to the studio: SRT. It copes with packet loss, and you decide how much delay you give for it.
- From the studio to the platform: RTMP(S). That is what the platforms accept, and on that route there is nothing to repair. Where there is RTMPS, take RTMPS: your stream key stays unreadable on the way.
- Several networks at once: SRTLA. It helps when no single network holds, and it needs a receiver that understands it. Your studio is not one of them yet.