Das SRT-Latenzfeld ist keine Geschwindigkeitseinstellung. Es ist die Zeit, die du dem Protokoll gibst, um zu merken, dass ein Paket fehlt, es erneut anzufordern und zurückzubekommen, bevor das Bild es braucht. Setz es zu klein, und der Stream friert bei jeder schlechten Mobilfunksekunde ein. Setz es vernünftig, und dieselbe schlechte Sekunde ist unsichtbar.
Für IRL ist der vernünftige Wert größer als der Studiowert. Hier steht, was er macht, was du eintragen sollst, und woran du erkennst, ob das überhaupt die Stellschraube ist.
Was der Wert tatsächlich ist
SRT läuft über UDP. Geht ein Paket verloren, bemerkt der Empfänger die Lücke und fordert dieses Paket beim Sender erneut an. Der Latenzwert ist, wie lange der Empfänger auf diese Antwort warten will, bevor er aufgeben und abspielen muss, was er hat. Alles, was innerhalb des Fensters ankommt, wird wieder einsortiert, und der Zuschauer sieht den Verlust nie. Alles, was das Fenster verpasst, wird verworfen, und genau das ist das Standbild oder der Klötzchenbrei, den du auf einer ruppigen Verbindung siehst.
Das Fenster muss also breiter sein als eine volle Umlaufzeit, mit Platz für mehr als einen Versuch. Haivision, die das Protokoll geschrieben haben, formulieren es als Vielfaches der Round-Trip-Zeit: grob das Drei- bis Vierfache auf einer sauberen Strecke, und mehr, je höher der Paketverlust steigt.
Was oft übersehen wird: das ist eine zweiseitige Einstellung. Dein Encoder nennt eine Latenz, das Relay nennt eine, und der Handshake nimmt die größere der beiden. Deinen Encoder unter den Wert des Relays zu drehen ändert nichts, ihn hochzudrehen wirkt immer.
Warum der IRL-Wert größer ist
Eine kabelgebundene Studioverbindung hat eine gleichmäßige Umlaufzeit. Ein Handy, das durch eine Stadt läuft, nicht. Die durchschnittliche Umlaufzeit zu einem nahen Relay liegt vielleicht unter einer Zehntelsekunde, aber ein Zellwechsel, eine überfüllte Funkzelle oder ein wieder aufwachendes Modem kann eine einzelne Umlaufzeit über eine halbe Sekunde treiben und mehrere davon hintereinander stapeln. Das Fenster wird nicht für den Durchschnitt bemessen. Es wird für die Spitze bemessen.
Mit SRTLA-Bonding hat dasselbe Fenster noch eine zweite Aufgabe. SRTLA verteilt deine Pakete über jedes Modem, das du hast. Fällt ein Modem aus, sind die Pakete, die darauf unterwegs waren, weg, und SRT fordert sie erneut an. SRTLA schickt diese Wiederholungen über die Modems, die noch gesund sind. Das Latenzfenster ist das Zeitbudget für diese Umleitung. Ein enges Fenster heißt, ein totes Modem kostet dich ein Standbild, obwohl zwei weitere laufen. Ein großzügiges Fenster heißt, es kostet dich nichts Sichtbares. Das ist der Hauptgrund, warum sich Bonding so viel geschmeidiger anfühlt als eine einzelne SRT-Verbindung auf demselben Handy.
Was du einstellen sollst
| Wo | Einstellung | Hinweise |
|---|---|---|
| Belabox (SRTLA) | 2000 ms | Der Standard. Bei ruppiger Route hoch, nicht runter. |
| Moblin auf dem iPhone (SRTLA) | 3000 ms | Der Standard. Lass ihn; er liegt ohnehin schon großzügig. |
| IRL Pro unter Android (SRTLA) | 2000 ms | Dasselbe Feld wie bei Belabox, derselbe Startpunkt. |
| LiveU Solo Pro (SRT) | 2500 ms | Was das Dashboard für diesen Encoder anzeigt. |
| Larix (SRT) | 2500 ms | Wird automatisch gesetzt, wenn du die Verbindung aus dem Dashboard öffnest. |
| OBS-Medienquelle, die das Relay abruft | latency=2000000 | Mikrosekunden, nicht Millisekunden. Das sind zwei Sekunden. |
Wenn du nur eine Sache aus der Tabelle mitnimmst: es gibt keinen guten Grund, auf einer Mobilfunkroute unter 2000 ms zu gehen, und selten einen Grund, über 4000 ms zu gehen. Dazwischen ist höher sicherer, und der Preis sind Sekundenbruchteile Verzögerung, die niemand im Chat spürt.
Die OBS-Seite rechnet in Mikrosekunden
OBS liest SRT über FFmpeg, und FFmpegs Latenzoption ist in Mikrosekunden. Zwei Sekunden sind 2000000. Tippst du 2000, bekommst du zwei Millisekunden, also gar kein Wiederherstellungsfenster, und der Abruf stottert selbst auf einer perfekten Heimverbindung. Die vollständige Abruf-URL steht im OBS-Einrichtungsguide.
Die Symptome lesen
Die meisten Latenzfragen heißen eigentlich "irgendwas stimmt nicht, ist das dieser Regler". Meistens ist es eines von drei Dingen, und nur eines davon ist die Latenz.
| Was du siehst | Was es bedeutet | Was du änderst |
|---|---|---|
| Kurze Standbilder oder Klötzchen, während die Bitratenkurve gesund bleibt | Pakete verpassen das Fenster | SRT-Latenz um 500 ms anheben und erneut testen |
| Die Bitrate fällt und das Bild wird weicher, aber es läuft weiter | Die adaptive Bitrate macht ihren Job auf einer dünnen Verbindung | An der Latenz nichts. Das ist der Kompromiss, der funktioniert. |
| Der Stream endet komplett | Die Verbindung ist gestorben, nicht der Puffer | Abbruchschutz: dein eigenes OBS hält die Übertragung. Siehe Stream live halten. |
Nur die erste Zeile behebt die Latenzeinstellung. Die zweite Zeile ist normal, und die dritte ist ein völlig anderes Problem. Die Latenz gegen einen Verbindungsabbruch hochzudrehen bringt nichts, weil keine Verbindung mehr da ist, auf der man sich erholen könnte.
SRT-Latenz ist nicht deine Zuschauerverzögerung
Das Fenster an deinem Encoder ist ein Sprung in einer Kette. Das Relay übergibt den Stream über einen zweiten SRT-Sprung mit eigenem Fenster an dein OBS. OBS hält einen Netzwerkpuffer, encodiert und schiebt zur Plattform. Die Plattform nimmt an, transkodiert, und der Player puffert obendrauf.
| Stufe | Ungefähr |
|---|---|
| SRT-Fenster im Encoder | 2 bis 3 s |
| SRT-Fenster Relay zu OBS | 2 s |
| OBS-Netzwerkpuffer und Encoding | unter 1 s |
| Plattform-Ingest, Transkodierung, Player | mehrere Sekunden |
Die erste Zeile von 2500 auf 1000 zu kürzen spart eineinhalb Sekunden aus einer Kette, die deutlich länger läuft, und du bezahlst diese Sekunde mit jedem Standbild, das das Fenster nicht mehr auffangen kann. Eine kurze Verzögerung verzeihen die Leute. Sie gehen, wenn das Bild ständig stehenbleibt. Wenn das Chat-Timing für ein Segment wirklich zählt, verschiebt der Low-Latency-Modus der Plattform die Gesamtsumme weit stärker als der SRT-Wert.
Wie du ohne Raten abstimmst
- Setz den Encoder auf den Wert aus der Tabelle und lass ihn in Ruhe.
- Streame den schlechtesten Abschnitt deiner Route: den Tunnel, die Menschenmenge, den Bahnsteig. Nicht dein Wohnzimmer.
- Friert das Bild ein, während die Bitrate hält, heb die Latenz um 500 ms an und fahr dieselbe Route noch einmal.
- Änder immer nur eine Sache. Latenz, Bitrate und Auflösung bewegen dieselben Symptome, und zwei gleichzeitig zu verstellen sagt dir nichts.
- Behalt die lokale Aufnahme. Schau dir Bewegung und Ton hinterher an, statt einer grünen Zahl im Dashboard zu vertrauen.
Das Relay ist die andere Hälfte der Einstellung
Dein Encoder entscheidet nur eine Seite. Unser Relay fährt standardmäßig ein entspanntes Latenzprofil, gebaut für gebondete Mobilfunk-Uplinks statt für eine Studioverbindung, ein vernünftiger Encoder-Wert landet also bei einem Empfänger, der raue Bedingungen erwartet. Kombinier das damit, das Relay in dein eigenes OBS zu holen, und die Verbindung draußen hört auf, das zu sein, was deine Übertragung beendet.
Noch unsicher beim Protokoll? SRTLA vs RTMP behandelt, wann SRT allein reicht und wann du Bonding brauchst.
FAQ
- Welche SRT-Latenz soll ich fürs IRL-Streaming nehmen?
- Fang encoderseitig mit 2000 bis 2500 ms an und lass es dabei, bis sich der Stream auf dem schlechtesten Abschnitt deiner Route als stabil erwiesen hat. Belabox nutzt standardmäßig 2000 ms und Moblin 3000 ms, beides ist so wie es ist in Ordnung. Unser Dashboard vergibt 2500 ms für SRT-Encoder mit einer Verbindung wie die LiveU Solo Pro und Larix.
- Muss die SRT-Latenz auf beiden Seiten übereinstimmen?
- Nein. Beide Seiten nennen im Handshake einen Wert, und die Verbindung nutzt den größeren. Deshalb bringt es nichts, deinen Encoder unter den Wert des Relays zu setzen, und deshalb lässt sich der OBS-Abruf getrennt von der Encoder-Seite abstimmen.
- Fühlt sich der Stream mit 2500 ms für den Chat langsam an?
- Nicht spürbar. Das SRT-Fenster ist ein Glied in einer Kette, die ohnehin schon einen zweiten SRT-Sprung in OBS, den eigenen Puffer von OBS und die Ingest- und Player-Verzögerung der Plattform enthält. Das Encoder-Fenster zu halbieren spart etwa eine Sekunde aus einer Kette, die deutlich länger ist.
- Warum will die OBS-Medienquelle 2000000 statt 2000?
- OBS liest die SRT-URL über FFmpeg, und FFmpeg nimmt die Latenz in Mikrosekunden. 2000000 sind zwei Sekunden. Tippst du dort 2000, bekommst du zwei Millisekunden, also praktisch gar kein Wiederherstellungsfenster.