Was ist SRT-Streaming? SRT vs. RTMP einfach erklärt

SRT ist ein Protokoll für den Videotransport, das für unzuverlässige Netzwerke gebaut wurde. So stellt es verlorene Pakete wieder her, das bewirkt die Latenz-Einstellung, so schlägt es sich gegen RTMP – und darum verlangen die meisten Plattformen trotzdem noch RTMP.

StreamHouse TeamVeröffentlicht 30. Oktober 2026 · Etwa 6 Min. Lesezeit

Auf dieser Seite

SRT (Secure Reliable Transport) ist ein Open-Source-Protokoll, um Livevideo über unberechenbare Netzwerke wie das öffentliche Internet zu senden. Es läuft über UDP, fordert verloren gegangene Pakete erneut an, lässt dich wählen, wie viel Verzögerung du gegen Zuverlässigkeit eintauschst, und kann den Stream verschlüsseln. Sender nutzen es, um hochwertige Feeds zwischen verschiedenen Standorten zu übertragen.

Es ist nicht überall ein Ersatz für RTMP, löst aber bestimmte Probleme sehr gut. So funktioniert es und wann sich der Einsatz lohnt.

Das Wichtigste in Kürze
SRT nutzt UDP und stellt verlorene Pakete innerhalb eines Latenzfensters wieder her, das du festlegst.
Es eignet sich für weite oder verlustbehaftete Verbindungen, etwa entfernte Veranstaltungsorte und Contribution-Feeds.
Die meisten Creator-Plattformen dokumentieren weiterhin RTMP- oder RTMPS-Ingest.
AES-Verschlüsselung mit gemeinsamer Passphrase schützt SRT-Feeds während der Übertragung.

Woher SRT stammt und welches Problem es löst

SRT wurde vom Videounternehmen Haivision entwickelt und 2017 als Open Source veröffentlicht. Inzwischen wird es von einer breiten Palette an Encodern, Decodern, Medienservern und Software unterstützt, darunter OBS und FFmpeg.

Das Problem, auf das es abzielt, ist schnell beschrieben: Das öffentliche Internet verliert Pakete und bringt sie durcheinander, besonders über weite Entfernungen, überlastetes WLAN oder Mobilfunkverbindungen. Klassische Rundfunkstrecken haben das mit dedizierten Leitungen oder Satellitenkapazität vermieden. SRT will stattdessen Zuverlässigkeit auf Broadcast-Niveau über gewöhnliche Internetverbindungen liefern.

Dabei kümmert es sich kaum darum, was im Stream steckt. SRT ist ein Transport, kein Videoformat, und transportiert meist einen MPEG-Transportstream mit H.264- oder HEVC-Video und AAC-Audio. Diese Flexibilität hat dazu beigetragen, dass professionelle Workflows es schnell übernommen haben.

So funktionieren Paketwiederherstellung und Latenzpuffer

RTMP setzt auf TCP auf, das verlorene Daten zwar erneut überträgt, aber die gesamte Verbindung verlangsamt, sobald ein Verlust erkannt wird. Auf verlustbehafteten Fernverbindungen äußert sich das in Hängern und Buffering.

SRT nutzt UDP und übernimmt die Wiederherstellung selbst. Der Empfänger hält Pakete in einem kurzen Puffer. Entdeckt er eine Lücke in der Reihenfolge, bittet er den Sender, genau das fehlende Paket erneut zu schicken. Kommt der Ersatz an, bevor dieser Moment des Videos den Puffer verlässt, merkt niemand weiter hinten in der Kette etwas.

Die Puffergröße ist die Latenz-Einstellung. Größere Werte verkraften schlechtere Netzwerke auf Kosten von Verzögerung; kleinere Werte halten die Verzögerung niedrig, verwerfen aber Pakete, die zu spät ankommen. Ein gängiger Startwert ist ein Mehrfaches der Round-Trip-Zeit zwischen Sender und Empfänger, bei instabilen Verbindungen höher. Tools geben die Latenz in unterschiedlichen Einheiten an, prüf also die Dokumentation.

Verschlüsselung, Stream-IDs und Verbindungsmodi

SRT bringt Funktionen mit, die RTMP von sich aus nicht bietet:

Verschlüsselung. AES mit einer Passphrase, die beide Seiten teilen, mit 128-, 192- oder 256-Bit-Schlüsseln. RTMP braucht für Verschlüsselung die separate Variante RTMPS.
Stream-ID. Eine optionale Kennung, mit der ein Empfänger-Port mehrere Feeds annehmen und jeden richtig weiterleiten kann – ein bisschen wie ein Streamschlüssel.
Verbindungsmodi. Eine Seite lauscht auf einem Port (Listener), die andere ruft ihn an (Caller). Ein dritter Modus, Rendezvous, lässt beide Seiten gleichzeitig verbinden, was helfen kann, wenn beide hinter Firewalls sitzen.

Weil SRT UDP nutzt, muss der UDP-Port des Listeners in jeder Firewall auf dem Weg offen sein – anders als bei den ausgehenden TCP-Verbindungen von RTMP. Zur RTMP-Seite siehe wie RTMP funktioniert und RTMP vs. RTMPS.

SRT vs. RTMP: Wo welches Protokoll gewinnt

Keins der beiden Protokolle ist einfach besser; sie sind für unterschiedliche Aufgaben gut.

SRT gewinnt bei der Contribution. Einen Feed von einem entfernten Veranstaltungsort, einem Außenteam oder über Mobilfunk zurück zu einer Produktionszentrale zu schicken, ist genau der Fall, in dem sich die Paketwiederherstellung auszahlt – ebenso bei Broadcast-Ketten, die Playout-Systeme, Decoder und Medienserver speisen.
SRT kommt mit Entfernung besser klar. Auf interkontinentalen Verbindungen mit Paketverlust und Jitter liefert ein gut eingestellter Latenzpuffer meist stabilere Ergebnisse als TCP-basiertes RTMP.
RTMP gewinnt bei der Kompatibilität. Nahezu jeder Encoder, Dienst und jede Plattform unterstützt es, und die Einrichtung besteht nur aus einer URL plus einem Schlüssel.
RTMP ist einfacher einzurichten. Keine UDP-Ports, keine Latenzabstimmung, keine Passphrasen, die abgesprochen werden müssen.

Eine praktische Regel: Nutz SRT zwischen Systemen, die du oder ein Partner kontrollieren, und RTMP oder RTMPS für den letzten Schritt in öffentliche Plattformen.

Warum YouTube, Twitch und die meisten Plattformen trotzdem RTMP verlangen

Wenn SRT so robust ist – warum dokumentieren die großen Creator-Plattformen dann weiterhin RTMP- und RTMPS-Ingest?

Erstens Kompatibilität: Plattformen wollen, dass sich jeder Streamer verbinden kann, von Handy-Apps bis zu älteren Hardware-Encodern, und RTMP ist das Protokoll, das sie alle sprechen. Zweitens senden die meisten Creator von zu Hause an einen nahe gelegenen Ingest-Server, wo TCP gut genug funktioniert. Drittens haben Plattformen über Jahre Authentifizierung, Schlüsselverwaltung und Monitoring rund um RTMP aufgebaut.

Dieses Bild verändert sich. Manche Plattformen und viele professionelle Videodienste akzeptieren SRT oder andere neuere Ingest-Protokolle. Zum Zeitpunkt des Schreibens gibt dir eine große Social-Media- oder Gaming-Plattform aber meist eine RTMP- oder RTMPS-URL. Der Guide zum Streamen an eigene RTMP-Ziele erklärt, wie diese Ziele funktionieren.

RTMP und SRT aus demselben Cloud-Stream senden

Viele Setups brauchen beide Protokolle gleichzeitig: RTMP für öffentliche Plattformen und SRT für ein Studio, einen Playout-Server oder den Empfänger eines Partners. Von einem Encoder zu Hause bedeutet das zwei Ausgänge und doppelten Upload.

StreamHouse erledigt das in der Cloud. Füge YouTube, Twitch oder Kick über RTMP oder RTMPS sowie einen eigenen SRT-Ausgang, der auf deinen Empfänger zeigt, zum selben Stream hinzu. Eine einzige Übertragung erreicht sie alle, und zusätzliche Ziele belegen keine zusätzlichen Stream-Slots.

Für vorab aufgezeichnetes Programm lädst du deine Videos hoch, die vorab auf ein einheitliches Encode-Profil vorbereitet werden, erstellst dann eine Playlist und startest oder planst sie. Der Stream läuft 24/7 in Schleife, verbindet sich nach Netzwerkaussetzern automatisch neu und läuft weiter, während dein Computer ausgeschaltet ist.

Häufig gestellte Fragen

Ist SRT besser als RTMP fürs Streaming?

Bei langen oder unzuverlässigen Netzwerkstrecken meist ja, weil SRT verlorene Pakete wiederherstellt, ohne die gesamte Verbindung auszubremsen. Große Plattformen bieten allerdings oft nur RTMP oder RTMPS an – die richtige Wahl hängt also davon ab, wohin dein Feed geht.

Hat SRT eine niedrigere Latenz als RTMP?

Das kann sein. Die Transportverzögerung bei SRT entspricht ungefähr dem Latenzpuffer, den du einstellst, und der kann in guten Netzwerken klein sein. Die Gesamtverzögerung für Zuschauer hängt aber auch von der Verarbeitung und Wiedergabe der Plattform ab, ein Protokollwechsel fühlt sich also nicht immer schneller an.

Kann OBS über SRT streamen?

Ja. Trag in OBS eine srt://-Adresse als benutzerdefinierten Server ein, mit Parametern wie Modus, Latenz und Passphrase direkt in der URL. Der empfangende Server oder Dienst muss SRT unterstützen und so eingerichtet sein, dass er die Verbindung annimmt.

Ist SRT standardmäßig verschlüsselt?

Nur wenn du eine Passphrase festlegst. Mit derselben Passphrase auf beiden Seiten verschlüsselt SRT den Feed per AES mit 128-, 192- oder 256-Bit-Schlüsseln. Ohne Passphrase wird er unverschlüsselt übertragen, leg also eine fest, wenn Feeds über das öffentliche Internet laufen.