RTMP und SRT transportieren beide dein Bild und deinen Ton über das Internet. Der Unterschied liegt darin, wie sie mit einem schlechten Netz umgehen. RTMP läuft über TCP und wartet auf jedes Paket, bis sich alles staut. SRT läuft über UDP, sendet verlorene Pakete gezielt nach und gibt nach einer festgelegten Zeit auf, statt den ganzen Stream aufzuhalten.
Die kurze Antwort für die Praxis: SRT für den Weg von dir ins Studio, RTMP(S) für den Weg zur Plattform.
RTMP in Kürze
RTMP ist das Protokoll, mit dem Twitch, YouTube, Kick und fast alle anderen Plattformen Streams entgegennehmen. RTMPS ist dasselbe mit Verschlüsselung. Du trägst eine Server-Adresse und einen Stream-Key ein, und es läuft.
Darunter liegt TCP. TCP garantiert, dass alle Daten vollständig und in der richtigen Reihenfolge ankommen. Für eine Webseite ist das genau richtig. Für Live-Video hat es einen Haken: Geht ein Paket verloren, wartet alles dahinter, bis es nachgeliefert ist. Bei einem stabilen Anschluss zu Hause fällt das nicht auf. Im Mobilfunk staut sich der Stream, die App kommt mit dem Senden nicht nach, und am Ende beendet die Plattform die Verbindung. Was dann passiert, beschreibt Warum dein Twitch-Stream beim Funkloch offline geht.
SRT in Kürze
SRT steht für „Secure Reliable Transport“. Es ist ein offenes Protokoll, entwickelt von Haivision und seit 2017 Open Source. Es wurde für genau die Strecken gebaut, auf denen RTMP Mühe hat: Mobilfunk, überlastete WLANs, lange Wege durchs öffentliche Internet.
SRT läuft über UDP. UDP garantiert nichts, es schickt Pakete einfach los. Die Zuverlässigkeit bringt SRT selbst mit: Der Empfänger merkt, welches Paket fehlt, und fordert genau dieses eine neu an. Dafür gibt es ein Zeitfenster, die Latenz. Kommt das Paket innerhalb dieser Zeit, merkt niemand etwas. Kommt es nicht, wird es übersprungen, und der Stream läuft weiter. Wie das im Einzelnen funktioniert, erklärt Was ist SRT?.
Der Vergleich
| RTMP(S) | SRT | |
|---|---|---|
| Transport | TCP | UDP |
| Verlorenes Paket | alles dahinter wartet | wird gezielt nachgesendet |
| Wenn das Nachsenden zu spät kommt | Stau, schließlich Abbruch | Paket wird übersprungen, kurzer Bildfehler |
| Verzögerung | wächst bei schlechtem Netz unkontrolliert | festes Zeitfenster, das du einstellst |
| Plattformen als Ziel | praktisch überall | selten |
| In Netzen mit Einschränkungen | kommt fast immer durch | scheitert, wenn das Netz UDP blockiert |
| Einrichtung | Server-Adresse und Stream-Key | Adresse mit Port, oft mit Stream-ID |
| Typischer Einsatz | vom Studio oder PC zur Plattform | von Kamera, Handy oder Encoder zum Studio |
Zwei Zeilen verdienen eine Erklärung.
Verzögerung. Bei SRT legst du fest, wie lange auf ein fehlendes Paket gewartet wird. Dieser Wert ist die Latenz, und er gilt für den ganzen Stream. Ein größerer Wert übersteht schlechtere Netze und kostet dafür etwas mehr Verzögerung. Bei RTMP gibt es keinen solchen Regler. Die Verzögerung ist bei gutem Netz klein und wächst bei schlechtem, ohne dass du es beeinflussen kannst.
Netze mit Einschränkungen. Viele Hotel-, Firmen- und öffentliche WLANs blockieren oder drosseln UDP. Dann kommt SRT nicht durch, obwohl das Netz sonst funktioniert. Der Ausweg sind die mobilen Daten des Handys oder ein Hotspot. Mehr dazu in UDP blockiert im Hotel-WLAN.
Warum nicht einfach SRT bis zur Plattform?
Weil die Plattformen RTMP(S) erwarten. Das ist kein Nachteil: Die Strecke von einem Rechenzentrum zur Plattform ist stabil, und dort tut RTMP, was es soll. Schwierig ist nur das erste Stück, von dir bis ins Internet. Für dieses Stück wurde SRT gemacht.
Daraus ergibt sich der übliche Aufbau für Streams von unterwegs:
- Kamera, Handy oder Encoder senden per SRT an eine Station im Rechenzentrum.
- Die Station sendet per RTMP(S) an die Plattform.
Diese Station kann ein eigener Server sein, ein Relay, ein gemietetes OBS oder ein Cloud-Studio. Die Unterschiede stehen in Relay, Cloud-OBS oder Cloud-Studio.
PGM.NINJA arbeitet genau so. Dein Studio nimmt bis zu acht Quellen per SRT an und sendet das fertige Programm per RTMP(S) an bis zu acht Ziele. Bricht eine Quelle weg, bleibt die Verbindung zur Plattform bestehen.
Wann RTMP völlig reicht
Wenn du von zu Hause über Glasfaser oder Kabel streamst und direkt an eine Plattform sendest, brauchst du kein SRT. Die Leitung ist stabil, und RTMP ist einfacher einzurichten. SRT lohnt sich, sobald eine der Strecken unsicher wird: Mobilfunk, fremdes WLAN, eine Kamera an einem anderen Ort.
Fazit
- Von dir zum Studio: SRT. Es verkraftet Paketverluste, und du bestimmst, wie viel Verzögerung du dafür gibst.
- Vom Studio zur Plattform: RTMP(S). Das ist, was die Plattformen annehmen, und auf dieser Strecke gibt es nichts zu reparieren.