SRT ist ein Übertragungsprotokoll für Live-Video, das für schlechte Netze gebaut wurde. Es schickt Bild und Ton über UDP und sendet Pakete, die unterwegs verloren gehen, innerhalb eines kurzen Zeitfensters noch einmal. So bleibt ein Stream sauber, auch wenn das Mobilfunknetz zwischendurch Daten verschluckt.

Der Name steht für „Secure Reliable Transport“. Entwickelt hat es die Firma Haivision, seit 2017 ist es Open Source. Heute senden es sehr viele Programme und Geräte: OBS, Streaming-Apps für das Handy, Hardware-Encoder, Produktionssoftware.

Warum UDP

Im Internet gibt es zwei grundlegende Arten, Daten zu verschicken. TCP stellt sicher, dass alles vollständig und in der richtigen Reihenfolge ankommt, und wartet dafür notfalls. UDP schickt Pakete los und kümmert sich um nichts weiter.

Für Live-Video ist Warten das Problem. Ein Bild, das zwei Sekunden zu spät kommt, ist wertlos, und alles dahinter verspätet sich mit. Deshalb baut SRT auf UDP und regelt selbst, was nachgesendet wird und was nicht. Den direkten Vergleich mit dem TCP-basierten RTMP findest du in SRT vs. RTMP.

Nachsenden: wie SRT Verluste repariert

Jedes Paket trägt eine laufende Nummer. Der Empfänger sieht daran sofort, wenn eines fehlt: Nach Nummer 41 kommt Nummer 43, also fehlt die 42. Er meldet das dem Sender, und der schickt genau dieses Paket noch einmal. Alle anderen Pakete laufen währenddessen normal weiter.

Kommt das nachgesendete Paket rechtzeitig, wird es an der richtigen Stelle eingefügt. Im Bild ist nichts zu sehen.

Das Latenzfenster

„Rechtzeitig“ ist bei SRT eine Zahl: die Latenz. Der Empfänger hält den Stream um diese Zeit zurück, bevor er ihn weitergibt. In diesem Puffer ist Platz, um Lücken zu füllen.

  • Eine kleine Latenz bedeutet wenig Verzögerung, aber wenig Zeit zum Nachsenden. Auf einer guten Leitung reicht das.
  • Eine große Latenz gibt dem Netz mehr Zeit. Der Stream übersteht mehr Verluste und ist dafür entsprechend später.

Schafft es ein Paket auch innerhalb des Fensters nicht, wird es übersprungen. Das Ergebnis ist ein kurzer Bildfehler oder eine Lücke im Ton, aber der Stream läuft weiter und staut sich nicht.

Die Latenz stellst du in deiner App ein. Bei PGM.NINJA puffert das Studio standardmäßig 200 ms; verlangt deine App mehr, gilt der größere Wert. Wie du den passenden findest, steht in SRT-Latenz einstellen.

Caller und Listener

Bei einer SRT-Verbindung gibt es zwei Rollen, die nur beschreiben, wer die Verbindung aufbaut:

  • Der Listener wartet an einer festen Adresse auf eine Verbindung.
  • Der Caller ruft diese Adresse an.

Das hat nichts damit zu tun, wer Video sendet. In der Praxis ist der Server der Listener, weil er eine feste, öffentlich erreichbare Adresse hat. Dein Handy oder dein Encoder ist der Caller, weil er aus jedem beliebigen Netz heraus anrufen kann. Viele Apps nennen das „Caller“-Modus, andere fragen gar nicht danach und wollen nur eine Adresse.

Bei PGM.NINJA ist dein Studio der Listener und deine App der Caller.

Die Stream-ID

Eine SRT-Adresse besteht aus Host und Port. Oft hängt noch eine Stream-ID daran:

srt://<host>:<port>?streamid=<id>

Die Stream-ID ist ein kurzer Text, den der Caller beim Verbindungsaufbau mitschickt. Der Server erkennt daran, zu welchem Eingang die Verbindung gehört. So können mehrere Kameras an denselben Port senden und landen trotzdem jeweils am richtigen Platz.

Manche Apps nehmen die ganze Adresse in einem Feld, andere wollen Host, Port und Stream-ID getrennt. Der Inhalt ist derselbe. In deinem Studio steht die Adresse jedes Eingangs auf dem Tab „Eingänge“. Sie bleibt normalerweise für jeden Stream gleich, du richtest sie also einmal ein.

Was SRT transportiert

SRT ist nur der Transportweg. Was darin steckt, ist fast immer ein MPEG-TS-Datenstrom mit Video und Ton, wie ihn jede SRT-App erzeugt. PGM.NINJA erwartet darin H.264-Video und AAC-Ton. Warum H.264 und nicht H.265, erklärt H.264 oder H.265 für den Weg ins Studio?.

SRT kann den Stream auch verschlüsseln, dafür gibt es in vielen Apps ein Feld für eine Passphrase. Ob du es brauchst, hängt von der Gegenstelle ab. Bei PGM.NINJA bleibt dieses Feld leer.

Wo SRT an Grenzen kommt

  • Blockiertes UDP. Viele Hotel-, Firmen- und öffentliche WLANs blockieren oder drosseln UDP. SRT kommt dann nicht durch. Der Ausweg sind mobile Daten oder ein Hotspot, siehe UDP blockiert im Hotel-WLAN.
  • Zu wenig Bandbreite. Nachsenden kostet zusätzliche Daten. Ist die Leitung schon mit dem Stream selbst voll, bleibt dafür nichts übrig. Eine niedrigere Bitrate hilft dann mehr als eine höhere Latenz, siehe Welche Bitrate für IRL-Streams.
  • Ein Netz, das ganz weg ist. SRT repariert Lücken, es überbrückt keine Minuten ohne Empfang. Dafür braucht es eine Gegenstelle, die den Stream zur Plattform solange hält. Mehr dazu in Warum dein Twitch-Stream beim Funkloch offline geht.

Eine Erweiterung namens SRTLA bündelt mehrere Mobilfunkverbindungen zu einer. PGM.NINJA nimmt das heute noch nicht an; eine einfache SRT-Verbindung aus denselben Apps funktioniert.

Weiterlesen