Wissen · Video Streaming & Networking
SRT verstehen.
Paket für Paket.
Wie gelangen Videodaten trotz Paketverlust, schwankender Laufzeiten und instabiler Verbindungen ans Ziel? Zwölf Erklärgrafiken zeigen die Mechanismen hinter Secure Reliable Transport.
Themen entdeckenZuverlässiger Transport beginnt im Netzwerk.
SRT ergänzt UDP um Mechanismen für zuverlässigen Datentransport. Für Live-Video müssen diese Mechanismen innerhalb eines begrenzten Zeitfensters arbeiten: Verlorene Pakete sollen wiederhergestellt werden, bevor die Anwendung sie benötigt. Pufferung, Wiederholung, optionale Fehlerkorrektur und redundante Verbindungen greifen dabei ineinander.
Die folgenden Kapitel erklären allgemeine SRT-Konzepte. Sie sind keine Zusage, dass jede SRT-Implementierung jede Funktion oder Kombination unterstützt. Für Robotweax SRT gelten die Dokumentation und Versionshinweise des Open-Source-Projekts.
SRT im Streaming-Testaufbau
SRT steht für Secure Reliable Transport. Das Protokoll überträgt Daten über UDP und ergänzt Mechanismen für Verlustbehandlung, Timing und optionale Verschlüsselung. Im gezeigten Video-Workflow erzeugt ein Encoder den komprimierten Medienstream; SRT transportiert ihn, und ein Decoder übernimmt die Wiedergabe. SRT ist also kein Videocodec.
Die Grafik erklärt
Beispiel eines SRT-Evaluationslabors: Testsignal und Encoder senden über eine gezielt beeinträchtigte Netzwerkstrecke an Decoder und Wiedergabe. Die Grafik verbindet den Medienpfad und ACK/NAK-Rückkanal mit einem Basistest, Variationen von RTT, Verlust, Jitter und Puffer sowie den zu erfassenden Messgrößen.
In der Praxis
Zuerst eine störungsfreie Referenz messen. Danach jeweils nur eine Größe verändern: Round-Trip Time (RTT, Hin- und Rücklaufzeit), Paketverlust, Jitter oder verfügbare Bandbreite. Den ACK/NAK-Rückkanal in die Netzwerktests einbeziehen und Bild, Ton sowie die gesamte Ende-zu-Ende-Latenz separat prüfen.
Connection Bonding: redundante Netzwerkpfade
Im Broadcast-Modus werden dieselben Daten über mehrere Verbindungen gesendet. Der Empfänger nutzt rechtzeitig eintreffende Kopien und verwirft Duplikate. Main/Backup verwendet dagegen einen aktiven Pfad mit einer Ausweichverbindung. Das kann Streams gegen den Ausfall einzelner Strecken absichern, setzt aber gruppenfähige, kompatible Endpunkte voraus.
Die Grafik erklärt
Zwei unabhängige Netzwerkpfade transportieren im gezeigten Broadcast-Modus Kopien desselben Datenstroms. Der gruppenfähige Empfänger führt die Pakete zusammen und verwirft Duplikate. Ergänzt werden Main/Backup, Ausfalltests und Messgrößen für Umschaltung und Wiederherstellung.
In der Praxis
Nicht nur einen Kabelausfall testen: Unterschiedliche Laufzeiten, Verlust auf jedem Pfad und die Wiederkehr einer ausgefallenen Verbindung gehören dazu. Beide Richtungen jeder Strecke berücksichtigen. Zwei Anschlüsse mit demselben gemeinsamen Ausfallpunkt sind keine vollständig unabhängigen Pfade.
ARQ: verlorene Pakete erneut anfordern
Automatic Repeat Request nutzt Sequenznummern, Rückmeldungen und einen Sendepuffer. Erkennt der Empfänger eine Lücke, kann er die fehlenden Sequenznummern über eine negative Bestätigung (NAK) melden. Der Sender überträgt die gespeicherten Pakete erneut. Positive Bestätigungen (ACKs) können den Empfang mehrerer Pakete gemeinsam bestätigen.
Die Grafik erklärt
Das Sequenzdiagramm verfolgt den Verlust von Paket 102: Der Empfänger erkennt eine Lücke, meldet sie per NAK und erhält eine erneut gesendete Kopie aus dem Sendepuffer. Der Empfangspuffer ergänzt die Lücke vor der geplanten Übergabe. ACKs können mehrere Pakete bestätigen.
In der Praxis
Die Reparatur braucht Zeit für Rückmeldung und erneute Übertragung sowie zusätzliche Bandbreite. Ein kleinerer Latenzpuffer lässt weniger Spielraum für RTT und Jitter. Entscheidend ist nicht allein, ob ein Paket wiederkommt, sondern ob es vor seiner Übergabe-Deadline eintrifft.
FEC: Paketverluste lokal rekonstruieren
Forward Error Correction sendet vorsorglich zusätzliche Reparaturdaten. Im XOR-Beispiel entsteht P aus D1, D2, D3 und D4. Fehlt nur D2, lässt es sich mit P und den drei übrigen Datenpaketen wieder berechnen. Für diese Reparatur entfällt eine erneute Übertragungsrunde; dafür werden schon vor einem Verlust Bandbreite und Zeit für die Reparaturgruppe benötigt.
Die Grafik erklärt
Ein vereinfachtes Row-only-Beispiel zeigt vier Datenpakete und ein XOR-Paritätspaket. Geht D2 verloren, kann der Empfänger es aus den übrigen Daten und der Parität lokal rekonstruieren. Die Grafik erläutert Overhead, Gruppenanordnung und die Zusammenarbeit mit ARQ.
In der Praxis
Row-, Column- und kombinierte Gruppen schützen unterschiedliche Verlustmuster. Die Zusammenarbeit mit ARQ ist konfigurierbar: „always“ lässt ARQ parallel arbeiten, „onreq“ fordert nicht durch FEC behobene Verluste an, „never“ verzichtet auf ARQ. Auch eine lokale Reparatur muss rechtzeitig abgeschlossen sein.
TSBPD: Daten zum vorgesehenen Zeitpunkt ausgeben
Timestamp-Based Packet Delivery gleicht schwankende Ankunftszeiten aus. Der Empfänger bildet die Senderzeitstempel auf seine eigene Uhr ab und plant die Übergabe anhand der ausgehandelten Latenz. Frühe Pakete warten im Empfangspuffer; verspätete oder reparierte Pakete haben innerhalb dieses Zeitfensters noch die Chance, die Lücke zu schließen.
Die Grafik erklärt
TSBPD nutzt Senderzeitstempel, deren Abbildung auf die Empfängeruhr und die ausgehandelte Latenz, um Pakete zeitgerecht an die Anwendung zu übergeben. Früh eintreffende Pakete warten im Puffer; das Beispiel stellt den ursprünglichen Abstand von 20 ms wieder her.
In der Praxis
Mehr Puffer schafft Zeit für Verlustbehandlung, erhöht aber die Transportverzögerung. Weniger Puffer reduziert diese Reserve. Die passende Einstellung ergibt sich aus der realen Netzwerkstrecke und dem Anwendungsziel – nicht aus einer universellen Millisekunden-Empfehlung.
AES-CTR: Vertraulichkeit für die Nutzdaten
Die Passphrase ist nicht direkt der Schlüssel für jedes Medienpaket. Aus Passphrase und Salt wird ein Key Encrypting Key (KEK) abgeleitet, der den zufälligen Stream Encrypting Key (SEK) schützt. AES-CTR erzeugt daraus mit paketbezogenen Zählern einen Schlüsselstrom. Eine XOR-Verknüpfung mit den Nutzdaten ergibt den verschlüsselten Payload; dieselbe Operation stellt ihn am Empfänger wieder her.
Die Grafik erklärt
Die Grafik trennt Schlüsselverwaltung von Nutzdatenverschlüsselung: Aus Passphrase und Salt wird der KEK abgeleitet, der den zufälligen Stream-Schlüssel SEK schützt. AES erzeugt mit SEK und paketbezogenen Zählern einen Schlüsselstrom. XOR verschlüsselt und entschlüsselt den Payload.
In der Praxis
Nutzdatenverschlüsselung und Integritätsschutz sind unterschiedliche Eigenschaften. CTR allein erkennt keine absichtliche Manipulation des Payloads. Sichtbare Header, Schlüsselverwaltung und die Anforderungen der gesamten Anwendung müssen bei der Sicherheitsbewertung separat berücksichtigt werden.
AES-GCM: verschlüsseln und Integrität prüfen
Galois/Counter Mode ergänzt die Verschlüsselung um einen Authentifizierungstag. In der dargestellten Verarbeitung gehen der Stream-Schlüssel, eine paketbezogene Nonce und Headerdaten als Additional Authenticated Data (AAD) ein. Der Empfänger prüft den Tag, bevor er die Nutzdaten freigibt. Manipulierte oder anderweitig nicht verifizierbare Daten werden abgelehnt.
Die Grafik erklärt
AES-GCM kombiniert Nutzdatenverschlüsselung mit einem Authentifizierungstag. Schlüssel, paketbezogene Nonce und Headerdaten als AAD gehen in die Verarbeitung ein. Der Empfänger prüft den Tag und gibt nur erfolgreich verifizierte Daten weiter; fehlgeschlagene Verifikation führt zur Ablehnung.
In der Praxis
Beide Endpunkte müssen einen kompatiblen GCM-Modus unterstützen und entsprechend konfiguriert sein. Eindeutige Nonces pro Schlüssel sind wesentlich. Authentifizierung repariert keine verlorenen Pakete: Dafür bleiben ARQ beziehungsweise FEC zuständig.
Packet Filter: eine interne Verarbeitungsstufe
Das Packet-Filter-Framework sitzt innerhalb der SRT-Endpunkte. Ein Filter kann Pakete verarbeiten und zusätzliche Filterpakete erzeugen. Empfangsseitig verarbeitet er diese Zusatzinformationen, bevor Daten an den Empfangspuffer gelangen. Der integrierte FEC-Filter ist ein konkretes Beispiel: Er ergänzt Reparaturpakete und kann fehlende Originaldaten rekonstruieren.
Die Grafik erklärt
Der Packet Filter ist als erweiterbare Verarbeitungsstufe innerhalb der SRT-Endpunkte dargestellt. Auf der Sendeseite kann er Pakete verarbeiten und zusätzliche Filterpakete einfügen; auf der Empfangsseite verarbeitet er diese und gibt Daten oder rekonstruierte Pakete an den Empfangspuffer weiter. FEC dient als konkretes Beispiel.
In der Praxis
Filter und Parameter werden über SRTO_PACKETFILTER eingestellt. Beide Endpunkte benötigen zueinander passende Konfigurationen. Reparaturpakete werden intern verarbeitet und nicht als zusätzliche Medieninhalte an die Anwendung weitergereicht.
HSv5: so entsteht eine SRT-Verbindung
Der Caller beginnt mit einer INDUCTION-Probe. Der Listener antwortet mit seiner HSv5-Unterstützung und einem SYN-Cookie. Anschließend sendet der Caller eine CONCLUSION mit dem Cookie und der HSREQ-Erweiterung; der Listener bestätigt mit HSRSP. Erweiterungen können Fähigkeiten, Verzögerungen, Schlüsselmaterial, Stream ID und Filterkonfiguration transportieren.
Die Grafik erklärt
Die Caller/Listener-Sequenz zeigt vier Nachrichten: INDUCTION-Probe, Antwort mit HSv5-Unterstützung und SYN-Cookie, CONCLUSION mit Cookie und HSREQ sowie die Antwort mit HSRSP. Optionale Erweiterungen transportieren Schlüsselmaterial und Konfiguration, bevor die Verbindung Daten überträgt.
In der Praxis
Unvereinbare Einstellungen können bereits beim Verbindungsaufbau zur Ablehnung führen. Bei Verbindungsproblemen daher nicht nur den UDP-Port prüfen, sondern auch Rollen, Erreichbarkeit in beiden Richtungen und die Einstellungen beider Endpunkte. Der Caller startet die Verbindung, muss aber nicht der Videosender sein.
Message Mode und Stream Mode: was die Anwendung erhält
Message Mode bewahrt Anwendungsnachrichten als getrennte Einheiten. Werden ABC und DEF als zwei Nachrichten gesendet, werden sie auch getrennt empfangen. Stream Mode erhält dagegen die Reihenfolge der Bytes, nicht die Grenzen der Schreibvorgänge. Der Empfänger kann beispielsweise AB, CD und EF lesen; bei Bedarf muss die Anwendung ihre eigene Nachrichteneinteilung ergänzen.
Die Grafik erklärt
Message Mode erhält Anwendungsnachrichten: ABC und DEF werden getrennt empfangen. Stream Mode erhält die Bytefolge, erlaubt aber andere Lesegrenzen, etwa AB, CD und EF. Die Tabelle ordnet beide API-Semantiken den Transferarten Live und File zu.
In der Praxis
„Stream Mode“ ist nicht gleichbedeutend mit „Video-Streaming“. Der SRT-Live-Transfer verwendet die Message API und verlangt Nachrichten innerhalb des konfigurierten Payload-Limits. File-Transfer kann Message- oder Stream-Semantik verwenden; die im Bild erwähnte Mehrpaket-Reassemblierung betrifft File/Message.
Stream ID: Verbindungsmetadaten statt Identitätsnachweis
Der Caller setzt SRTO_STREAMID vor dem Verbindungsaufbau. Die Listener-Anwendung erhält diese Information im Handshake und entscheidet, welche Ressource und Zugriffsregel passen. Im Beispiel „#!::r=studioA,m=publish,u=alice“ bezeichnet r die Ressource, m die gewünschte Aktion und u einen behaupteten Nutzernamen. Diese strukturierte Schreibweise ist eine Konvention, kein zwingendes Format für jeden Dienst.
Die Grafik erklärt
Der Caller setzt eine Stream ID vor dem Verbindungsaufbau. Die HSv5-CONCLUSION transportiert sie zum Listener, dessen Anwendung Ressourcenwahl und Zugriffspolitik auswertet. Das Beispiel #!::r=studioA,m=publish,u=alice erläutert Resource, Aktion und behaupteten Nutzernamen.
In der Praxis
Ein Dienst kann mehrere Verbindungen auf einem Listener annehmen und anhand ihrer Stream IDs verschiedenen Ressourcen zuordnen. Die Anwendung muss die Angaben selbst auswerten und Berechtigungen durchsetzen. Geheimnisse wie Verschlüsselungspassphrasen gehören nicht in eine öffentlich sichtbare Stream ID.
Statistiken: Transportqualität richtig beurteilen
Die SRT-Bibliothek führt pro Socket Ereigniszähler, Timing-Schätzungen und Pufferwerte. Eine Anwendung liest diese mit srt_bstats aus und erstellt daraus Logs, Diagramme oder Alarme. Kumulative Werte gelten seit Erstellung des Sockets, Intervallwerte seit dem letzten Zurücksetzen und momentane Werte beschreiben den aktuellen Zustand oder eine Schätzung.
Die Grafik erklärt
SRT führt pro Socket Zähler für Paketereignisse, Timing-Schätzungen und Pufferzustand. Anwendungen lesen lokale Snapshots über srt_bstats aus und erzeugen daraus Logs oder Diagramme. Die Grafik unterscheidet kumulative, intervallbezogene und momentane Werte und zeigt die Bedeutung des clear-Parameters.
In der Praxis
Mit clear = 1 werden Intervallzähler nach dem Lesen zurückgesetzt, die kumulativen Gesamtwerte bleiben erhalten. Für Vergleiche braucht es einheitliche Abfrageintervalle und Einheiten. Beide Endpunkte lokal erfassen und bei Bedarf zusammenführen. Verlustmeldungen, Wiederholungen, endgültige Drops und tatsächliche Bildfehler sind unterschiedliche Messgrößen.
Das Zusammenspiel
Drei Fragen für jeden SRT-Workflow
- Wie viel Zeit steht zur Verfügung? RTT und Jitter verbrauchen einen Teil des Zeitfensters für ARQ oder FEC. Den SRT-Puffer und die gesamte Ende-zu-Ende-Latenz getrennt betrachten.
- Welche Reserve bietet das Netzwerk? Wiederholungen und FEC benötigen zusätzliche Bandbreite. Bei Broadcast/Backup-Bonding muss jeder nutzbare Pfad den vollständigen Stream tragen können.
- Was unterstützen die konkreten Endpunkte? Verschlüsselung, Filter, Gruppen und API-Modi anhand der jeweiligen Version und Konfiguration prüfen und das Zusammenspiel unter realistischen Störungen testen.
Robotweax Open Source
Vom Protokoll zum Projekt.
Quellcode, Dokumentation und die unterstützten Profile von Robotweax SRT findest du auf GitHub.
Zu den Grafiken und Quellen
Die zwölf englischen Illustrationen und ihre deutschen Beschreibungen stammen aus der Robotweax-Erklärsammlung vom 9. September 2026. Die KI-generierten Grafiken sind schematische Lernmodelle, keine Screenshots, Benchmarks oder Sicherheitsnachweise. Verwendet wird die korrigierte Statistikgrafik; die archivierte Vorversion ist nicht enthalten.
Die Quellenhinweise unter den Kapiteln benennen die zur Erstellung verwendete öffentliche Haivision-Dokumentation, Implementierungsquellen und den SRT-Protokollentwurf. Die Sammlung bezieht sich auf den bei ihrer Erstellung konsultierten Stand, nicht auf eine bestimmte Robotweax-Version. Die zugrunde liegenden Entwicklungsstände können sich ändern. Beispiele und Zahlen sind keine universellen Einstellungen oder garantierten Leistungswerte.