Inhalt dieses Guides
SRT-Overhead fürs IRL-Streaming verstehen: Retransmits, Paketverlust, Kanalkapazität und warum die Streambitrate nicht die komplette Uploadleitung belegen darf.
Die mobile Übertragung als Gesamtkette
Zwischen Kamera und Plattform können Strom, Funk, Encoder und Transport getrennt ausfallen.
- Uplink unter Last prüfen
- Latenzreserve planen
- Failover unter Realbedingungen testen
Prüfe die Stationen nacheinander.
Hier werden keine Messwerte erhoben. Du prüfst lokal und dokumentierst die Ergebnisse selbst.
Mobilfunk
Ein einzelner Speedtest sagt wenig über Schwankungen während Bewegung und Funkzellenwechsel.
Upload und Stabilität entlang der tatsächlichen Route wiederholt unter Streaminglast prüfen.
Starke Einbrüche? Bitrate reduzieren, Reserve oder alternative Funkstrecke planen.
Transport / Latenz
SRT-Puffer und Netzwerkpfad beeinflussen Glitches und Verzögerung gemeinsam.
RTT, Verlust und Transportlatenz beobachten; Teststream mit Bewegung und Handover durchführen.
Puffer unzureichend? Latenz anhand reproduzierbarer Verlustsituationen justieren.
Strom / Failover
Stromwechsel und Modemausfall müssen den gesamten Stream überstehen, nicht nur einen Teil.
Unter sicheren Bedingungen Powerbankwechsel, Backup-Uplink und automatische Wiederaufnahme testen.
Abbruch? Aufbau vereinfachen und Ausfallpfad vor dem nächsten Außeneinsatz testen.
Fortschritt bleibt auf diesem Gerät und wird nicht übertragen.
IRL-Arbeitsmodus
IRL ist ein Gesamtsystem aus Funk, Transport, Strom, Thermik und Audio. Teste diese Ebenen getrennt.
Welche Ebene ist aktuell am schwächsten?
Peak-Speed allein reicht nicht. Stabilität, Handover und Zelllast bestimmen den Livebetrieb.
Transportprotokoll und Redundanz müssen zum Verhalten deiner Mobilfunkpfade passen.
Ein perfekter Uplink hilft nicht, wenn Smartphone, Hub, Mikrofon oder Stromversorgung ausfallen.
SRT kann verlorene Pakete erneut senden. Genau diese Zuverlässigkeit benötigt zusätzliche Bandbreite. Wenn dein Videostream bereits die gesamte verfügbare Uploadkapazität belegt, bleibt für Retransmits kein Platz – und der Mechanismus, der den Stream retten soll, konkurriert mit dem eigentlichen Stream.
Nominale Streambitrate ist nicht Linkbedarf
Zur Video- und Audiobitrate kommen Transportdaten und bei Verlust Wiederholungen. Haivision beschreibt den Bandwidth Overhead als Anteil, der für SRT-Steuerung und wiederhergestellte Pakete reserviert wird. Der notwendige Wert hängt vom Verlust des konkreten Pfads ab.
Paketverlust erhöht den Bedarf
Bei einem sauberen Link sind wenige Wiederholungen nötig. In einer überlasteten Funkzelle kann die Zahl deutlich steigen. Deshalb sollte der Overhead nicht als fixer „SRT braucht immer X Prozent“-Wert verkauft werden. Miss den Pfad und beobachte Resent Bytes beziehungsweise Loss-Statistiken.
Haivision empfiehlt konservative Kapazität
In der aktuellen Tuning-Anleitung wird neben der mathematischen Overhead-Bedingung ein konservativer Ansatz beschrieben, bei dem nur etwa 75 Prozent der gemessenen Kanalkapazität für Streambandbreite inklusive Overhead verplant werden. Das ist eine hilfreiche Denkweise, keine Garantie für jedes Mobilfunknetz.
Bitrate zuerst senken, nicht nur Overhead erhöhen
Wenn der Link dauerhaft zu knapp ist, bringt ein immer größerer Overheadwert nichts. Die zusätzlichen Retransmits müssen ebenfalls durch denselben Engpass. Senke Videoqualität oder Auflösung, bis genügend reale Reserve entsteht.
Bonding verändert die Betrachtung
Bei mehreren WANs muss die verfügbare Gesamtbandbreite nicht nur addiert, sondern nach Stabilität bewertet werden. Ein langsamer oder stark schwankender Link kann einen Bonding-Algorithmus belasten. Gute Systeme gewichten oder glätten Pfade statt blind alles gleich zu behandeln.
Praktischer Test
- Stream mit Zielbitrate senden.
- RTT und Loss über mindestens 15 Minuten beobachten.
- Resent Bytes auswerten.
- Uploadreserve erhöhen oder Streambitrate senken.
- Test auf der realen Route wiederholen.
Overhead nicht mit FEC verwechseln
SRT nutzt primär Wiederholungen verlorener Pakete innerhalb des Latenzfensters. Der zusätzliche Bandbreitenbedarf entsteht deshalb dynamisch mit den Netzbedingungen. Plane nicht so, als wäre jeder Stream dauerhaft um einen festen Prozentsatz größer. Miss stattdessen den realen Pfad und beobachte, wie stark die Wiederholungen bei Bewegung, Zellwechsel und Auslastung tatsächlich ansteigen.
