SRTLA, SRT oder RTMP: Das richtige Protokoll für IRL-Streams

Für IRL-Streams ist SRT meist die bessere Wahl als RTMP, und SRTLA ist die beste Option, wenn du über mehrere Verbindungen gleichzeitig senden kannst. RTMP brauchst du trotzdem, weil Plattformen es erwarten, aber es gehört auf die stabile letzte Strecke zwischen Server und Plattform und nicht ins Mobilfunknetz.

Dieser Ratgeber erklärt, wie die drei Protokolle funktionieren, wie sie sich im Mobilfunk verhalten und wie du die SRT-Latenz richtig einstellst.

Was ist RTMP?

RTMP (Real-Time Messaging Protocol) wurde von Adobe spezifiziert und 2009 als offene Spezifikation veröffentlicht. Es ist dafür gedacht, über einen zuverlässigen Transport wie TCP zu laufen, der garantiert, dass alle Nachrichten der Reihe nach ankommen (RTMP-Spezifikation). Der IETF-Entwurf zu SRT nennt RTMP den De-facto-Standard für die Zuführung über das öffentliche Internet. Deshalb spricht es praktisch jeder Encoder, jede App und jede Plattform.

Die Schwäche kommt aus demselben Aufbau. Weil RTMP auf TCP setzt, ist es nur bei Verbindungen mit niedriger Round-Trip-Time akzeptabel zuverlässig, und die TCP-Überlastkontrolle verhindert, dass die volle Bandbreite genutzt wird. Für ein Smartphone, das zwischen Funkmasten wechselt, passt das schlecht.

Klassisches RTMP hat außerdem Grenzen bei den Codecs: Es unterstützt nur zwei Audiokanäle und eine begrenzte Auswahl an Codecs, also kein HEVC, VP9 oder AV1. Die Enhanced-RTMP-Spezifikation ergänzt diese Codecs, und YouTube nennt für RTMP(S) inzwischen H.264, H.265 und AV1. Deine Software und die Plattform müssen das aber beide unterstützen. RTMPS ist RTMP in einer verschlüsselten SSL-Verbindung, und YouTube empfiehlt es genau deshalb.

Was ist SRT?

SRT (Secure Reliable Transport) ist ein quelloffenes Protokoll, das im öffentlichen GitHub-Repository von Haivision entwickelt und in einem IETF-Internet-Draft beschrieben wird. Es läuft über UDP und ergänzt die Zuverlässigkeit, die UDP allein nicht bietet. Das wichtigste Verfahren ist ARQ (Automatic Repeat reQuest): Bemerkt der Empfänger ein fehlendes Paket, fordert er es beim Sender erneut an. Außerdem unterstützt das Protokoll Forward Error Correction und ein eigenes Connection Bonding.

Drei Eigenschaften sind für IRL-Streaming wichtig:

• Latenz-Puffer: Der Empfänger hält jedes Paket für eine eingestellte Zeit zurück, bevor er es weitergibt. In diesem Fenster können verlorene Pakete erneut gesendet werden, und das ursprüngliche Timing des Streams wird wiederhergestellt. Zu spät eintreffende Pakete lassen sich verwerfen, damit die Verzögerung konstant bleibt, statt immer weiter zu wachsen.
• Verschlüsselung: SRT unterstützt AES-Verschlüsselung mit 128, 192 oder 256 Bit.
• Codec-unabhängig: SRT kennt den Inhalt nicht und transportiert jeden Codec, jede Auflösung und jede Bildrate, auch HEVC.

Der Haken ist eingebaut: Der Puffer erzeugt absichtlich Verzögerung. Du musst also einen Latenzwert wählen, der zu deinem Netz passt (dazu unten mehr).

Was ist SRTLA?

SRTLA ist ein SRT-Transport-Proxy mit Link Aggregation. Es stammt aus dem BELABOX-Projekt und überträgt SRT-Datenverkehr über mehrere Netzwerkverbindungen, um Kapazität zu bündeln und Ausfälle abzufedern. Der Verkehr wird dynamisch nach der jeweiligen Netzqualität verteilt. Gedacht ist das Ganze für das Bonding von Mobilfunkmodems beim Livestreaming.

SRTLA ersetzt SRT nicht. Es sitzt zwischen SRT-Sender und SRT-Empfänger: Dein Gerät sendet den SRT-Stream zum Beispiel über zwei SIM-Karten oder über eine SIM und WLAN gleichzeitig, und ein Empfänger, der SRTLA versteht, setzt die Pakete wieder zusammen und gibt sie als normalen SRT-Stream weiter. Daraus folgen drei praktische Dinge:

• Du brauchst einen SRTLA-fähigen Sender. Die kostenlose iOS-App Moblin kann zum Beispiel eine Mobilfunk-, eine WLAN- und mehrere Ethernet-Verbindungen gleichzeitig nutzen. Auch IRL Pro und BELABOX-Geräte bieten SRTLA-Bonding.
• Du brauchst einen SRTLA-Empfänger. Eine Streaming-Plattform oder ein einfacher SRT-Listener kann das nicht, also muss ein Server mit SRTLA-Eingang dazwischen sitzen.
• Es braucht Feintuning. Über verschiedene Verbindungen kommen Pakete in wechselnder Reihenfolge an. Die README verlangt deshalb Empfängeroptionen wie lossmaxttl und eine passende Latenz.

RTMP, SRT und SRTLA im Vergleich

Warum Plattformen RTMP wollen und ein Server dazwischen sitzt

Die Encoder-Dokumentation der großen Plattformen dreht sich weiter um RTMP. YouTube nennt RTMP/RTMPS als Encoder-Protokoll (HLS ist die Alternative), und Twitchs Entwicklerdokumentation beschreibt das Senden des Streams per RTMP zu Twitch. SRT und SRTLA kannst du deshalb in den meisten Fällen nicht direkt an eine Plattform schicken.

Ein Server löst das und bringt einen zweiten Vorteil. Die Kette sieht so aus:

1. Dein Smartphone oder Encoder sendet SRT oder SRTLA (oder RTMP) an einen Server.
2. Deine Streaming-Software, etwa OBS Studio, holt den Stream von diesem Server ab.
3. OBS sendet den fertigen Stream per RTMP(S) über eine stabile Verbindung an die Plattform.

Die wacklige Mobilfunkstrecke nutzt so das tolerantere Protokoll, und die Plattform bekommt das erwartete Protokoll über eine Verbindung, die sich nicht bewegt. Bricht das Mobilfunksignal kurz weg, streamt OBS weiter zur Plattform, und der Stream endet für deine Zuschauer nicht. Encoder und OBS verbinden sich beide ausgehend mit dem Server, du musst also keine Ports an deinem Router öffnen.

Genau das übernimmt unser IRL Endpoint Server für dich, wenn OBS auf deinem eigenen PC läuft. Er nimmt RTMP, SRT und SRTLA als Eingang an. Hast du keinen Streaming-PC, lässt der IRL Broadcasting Server OBS Studio in der Cloud laufen und akzeptiert dieselben drei Eingänge. Einen größeren Überblick über das IRL-Setup findest du in unserem IRL-Streaming-Ratgeber.

So stellst du die SRT-Latenz ein

Die SRT-Latenz ist nicht die gesamte Verzögerung zwischen Kamera und Zuschauer. In der Haivision-Dokumentation beschreibt sie nur die Verzögerung durch das Senden über das Netzwerk. Encoding, Decoding, OBS und die Plattform kommen noch dazu. Die Einstellung legt in Wahrheit fest, wie lange der Empfänger zusätzlich wartet, um verspätete Pakete und erneute Übertragungen auszugleichen.

Die OBS-Wissensdatenbank nennt eine Faustregel für die wichtigste Option:

• Der Standardwert liegt bei 120 ms.
• Der Wert sollte mindestens das 2,5-Fache der Round-Trip-Time zwischen Encoder und Server in Millisekunden betragen.
• In einer FFmpeg-artigen URL, wie OBS sie verwendet, ist die Einheit Mikrosekunden. Eine Latenz von 1 Sekunde schreibst du als latency=1000000.

Beispiel: Zeigt ein Ping zu deinem Server eine Round-Trip-Time von 80 ms, ergibt die Regel mindestens 200 ms, du würdest also srt://SERVER:PORT?latency=200000 eintragen. Nimm dafür die genaue Adresse und den Port aus deinem Kundenportal. In OBS lassen sich solche Optionen an die SRT-URL einer Medienquelle oder eines benutzerdefinierten Stream-Ziels anhängen.

Für Streams zu unseren Servern empfehlen wir eine Latenz von 2 Sekunden. Je nach App gibst du sie als 2000 (Millisekunden) oder 2000000 (Mikrosekunden) ein. Meist gibt es dafür ein eigenes Feld. Falls nicht, hängst du sie an die SRT-URL an, zum Beispiel srt://<server>:<port>?streamid=publish:publish/<streamkey>&latency=2000. Ein niedrigerer Wert ist möglich, wir empfehlen 2 Sekunden aber bewusst zugunsten der Stabilität.

Ein paar Hinweise dazu:

• Die Einheiten unterscheiden sich. Die SRT-Bibliothek und die SRTLA-README verwenden Millisekunden, FFmpeg-artige URLs Mikrosekunden. Prüfe, welche Einheit deine App erwartet, bevor du einen Wert eingibst.
• Beide Seiten handeln den Wert aus. Laut SRT-Entwurf ergibt sich die Latenz einer Verbindung aus dem höheren der beiden vorgeschlagenen Werte von Sender und Empfänger. Wenn du sie nur auf einer Seite senkst, bringt das nichts, solange die andere Seite mehr verlangt.
• Mobilfunk und Bonding brauchen Reserve. Die Regel oben ist ein Minimum und keine Empfehlung. Ein größeres Fenster bedeutet mehr Zeit für erneute Übertragung und Umsortierung, aber auch mehr Verzögerung. Die SRTLA-README nutzt in ihrem Beispiel-Empfänger etwa latency=2000 (ms) zusammen mit lossmaxttl.
• Ändere immer nur eine Sache und teste unterwegs, nicht nur am Schreibtisch.

Serverstandort und Latenz

Weil die minimale SRT-Latenz mit der Round-Trip-Time wächst, spielt die Entfernung eine Rolle. Ein Server in deiner Nähe hat eine kürzere Round-Trip-Time. So kannst du ein kleineres Latenzfenster fahren oder die gleiche Stabilität mit weniger Verzögerung erreichen. Dasselbe gilt für die letzte Strecke: Twitch empfiehlt zum Beispiel Ingest-Endpunkte anhand des Netzwerkpfads zu deinem Gerät.

Wir bieten Serverstandorte in den Regionen USA, Europa, Asien und Südamerika an. Beim IRL Endpoint Server kannst du im Standard-Tarif zwischen ihnen wählen und im Kundenportal jederzeit wechseln, was auf Reisen hilft. Im Dedicated-Tarif richten wir einen eigenen Endpunkt für dich ein, standardmäßig am Standort, der deiner Rechnungsadresse am nächsten liegt.

Welches Protokoll passt zu dir?

• Eine Verbindung, moderne App: nimm SRT und stelle die Latenz passend zur Round-Trip-Time ein.
• Zwei oder mehr Verbindungen: nimm SRTLA, wenn deine App es unterstützt und dein Server es annimmt.
• App oder Kamera kann nur RTMP: nimm RTMP. Es funktioniert, ist aber weniger tolerant bei schwachem Netz.
• HEVC: SRT ist codec-unabhängig. Prüfe, ob die ganze Kette vom Encoder über OBS bis zur Plattform es unterstützt. Stelle das Keyframe-Intervall im Encoder auf 2 Sekunden und deaktiviere bei HEVC auf Apple-Geräten die B-Frames, falls deine App das anbietet.

Häufige Fragen

Ist SRT besser als RTMP für IRL-Streaming?

Für die mobile Strecke meistens ja. SRT läuft über UDP und überträgt verlorene Pakete innerhalb eines einstellbaren Latenzfensters erneut, RTMP setzt dagegen auf TCP und bleibt nur bei Verbindungen mit niedriger Round-Trip-Time zuverlässig. Für die Verbindung vom Server oder von OBS zur Plattform bleibt RTMP die übliche Wahl.

Was ist der Unterschied zwischen SRT und SRTLA?

SRT ist das Transportprotokoll für eine Verbindung. SRTLA überträgt SRT-Verkehr über mehrere Netzwerkverbindungen gleichzeitig, etwa zwei SIM-Karten, um Kapazität und Ausfallsicherheit zu erhöhen. Dafür brauchst du eine SRTLA-fähige App und einen Empfänger, der SRTLA versteht.

Kann ich SRT direkt zu Twitch oder YouTube streamen?

Die Encoder-Dokumentation beider Plattformen dreht sich um RTMP(S), bei YouTube kommt HLS als Alternative dazu. Willst du auf der mobilen Strecke SRT oder SRTLA nutzen, setze einen Server und OBS zwischen dein Gerät und die Plattform.

Welche Latenz sollte ich für SRT einstellen?

Für Streams zu unseren Servern empfehlen wir 2 Sekunden, je nach App eingegeben als 2000 (Millisekunden) oder 2000000 (Mikrosekunden). Ein niedrigerer Wert ist möglich, die 2 Sekunden sind aber eine bewusste Entscheidung zugunsten der Stabilität. Als allgemeine Regel nennt die OBS-Wissensdatenbank mindestens das 2,5-Fache der Round-Trip-Time zu deinem Server, der Standardwert liegt bei 120 ms. Mobilfunknetze und gebündelte Verbindungen brauchen meist mehr Reserve, was mehr Verzögerung bedeutet.

Unterstützt der IRL Endpoint Server alle drei Protokolle?

Ja. Der IRL Endpoint Server und der IRL Broadcasting Server nehmen RTMP, SRT und SRTLA als Eingang an.