Ein Stream aus dem Studio hat feste Kabel und eine berechenbare Internetverbindung. Beim IRL-Streaming bewegt sich dagegen alles: die Person, die Kamera, die Funkzelle und manchmal sogar das Wetter. Ein voller 5G-Balken ist deshalb noch keine Garantie für einen stabilen Upload. Entscheidend ist, ob über die gesamte Strecke hinweg genügend konstante Upload-Kapazität vorhanden ist.
Dieser Beitrag ergänzt bewusst klassische Netzwerk- und OBS-Ratgeber. Es geht nicht um LAN, WLAN oder die perfekte Szenensammlung am Schreibtisch, sondern um schwankenden Mobilfunk, kontrollierte Ausfälle und eine möglichst unauffällige Rückkehr in den Livebetrieb.
Warum ein mobiler Stream trotz gutem Empfang abreißen kann
Die Anzeige auf dem Smartphone beschreibt nur einen Teil der Verbindung. Auf einer belebten Veranstaltung können viele Geräte dieselbe Funkzelle belasten. Beim Laufen oder Fahren wechselt das Gerät außerdem zwischen Zellen. Tunnel, dichte Bebauung, Innenräume und große Menschenmengen verändern die verfügbare Datenrate innerhalb weniger Sekunden.
Typische Ursachen sind:
- kurzfristige Paketverluste und stark schwankende Laufzeiten,
- eine überlastete Funkzelle trotz guter Signalstärke,
- ein Wechsel zwischen 4G und 5G oder zwischen Funkzellen,
- thermische Drosselung des Smartphones oder Encoders,
- ein ausgelasteter Upload durch weitere Apps,
- eine zu hoch gewählte Bitrate ohne Reserve.
OBS beschreibt verlorene Frames meist als Zeichen einer instabilen Verbindung oder unzureichender Bandbreite. „Dynamic Bitrate“ kann dann die Bitrate absenken, beseitigt aber nicht die Ursache (OBS: Stream Connection Troubleshooting). Software kann einen Engpass abfedern, aber keine fehlende Funkversorgung erzeugen.
Die stabilere Architektur: erst zum eigenen Ingest, dann zur Plattform
Beim einfachsten Aufbau sendet das Mobilgerät direkt zu YouTube, Twitch oder einer anderen Plattform. Das ist bequem, bietet bei einem Abbruch aber wenig Gestaltungsspielraum. Robuster ist eine zweistufige Architektur:
- Das mobile Gerät sendet zu einem erreichbaren Ingest-Server.
- Der Server übernimmt die Ausgabe zur Plattform.
- Fällt der mobile Eingang aus, sendet der Server eine vorbereitete Fallback-Szene weiter.
- Sobald das mobile Signal zurückkehrt, schaltet die Ausgabe kontrolliert wieder auf das Livebild.
Die Plattformverbindung bleibt dadurch auf der Server-Seite bestehen. Für das Publikum erscheint statt eines harten Abbruchs beispielsweise eine ruhige Szene mit dem Hinweis, dass die mobile Verbindung wiederhergestellt wird. Der Server kann außerdem zentral aufzeichnen und überwachen. Das ersetzt keine gute Mobilfunkverbindung, trennt aber zwei Probleme: Der mobile Uplink darf kurz ausfallen, ohne dass sofort die gesamte Sendung endet.
RTMP oder SRT: Was das Protokoll wirklich verändert
RTMP beziehungsweise RTMPS ist weit verbreitet und wird von vielen Plattformen direkt angenommen. YouTube empfiehlt für Live-Encoder RTMPS, eine konstante Bitrate und Keyframes im Abstand von zwei Sekunden (YouTube: Live encoder settings).
SRT – Secure Reliable Transport – wurde dagegen für unberechenbare Netzwerke entwickelt. Es kann Paketverlust, Jitter und schwankende Bedingungen mit Puffern, erneuter Übertragung verlorener Pakete und Verschlüsselung abfedern. Die SRT Alliance beschreibt es als Open-Source-Technologie für sichere Videoübertragung über unvorhersehbare Netzwerke (SRT Alliance); Haivision erläutert die Mechanismen sowie den Zusammenhang zwischen Latenz und Fehlerkorrektur (Haivision: SRT im Überblick).
Wichtig ist die Grenze: SRT bündelt nicht automatisch mehrere Mobilfunkanschlüsse und erzeugt keine Bandbreite. Wenn die Verbindung vollständig verschwindet, kann auch SRT nichts übertragen. Es macht kurze Störungen jedoch oft weniger sichtbar und eignet sich gut für die Strecke zum eigenen Ingest-Server.
Bitrate mit Reserve statt Rekordwert
Eine hohe Bitrate sieht im Idealfall etwas besser aus, erhöht unterwegs aber das Ausfallrisiko. Sie sollte nicht auf dem besten Messergebnis einer Route basieren, sondern auf einem realistischen Minimum. YouTube rät, die Upload-Bandbreite zu testen und etwa 20 Prozent Reserve einzuplanen (YouTube: Tipps zum Livestreaming). Beim Mobilfunk darf die Sicherheitsmarge größer sein.
Ein sinnvoller Ansatz:
- Auflösung und Bildrate passend zum Inhalt wählen.
- Die Bitrate so setzen, dass auch schwächere Abschnitte tragfähig bleiben.
- Adaptive Bitrate aktivieren, wenn die Lösung sie zuverlässig unterstützt.
- Audio priorisieren: Ein kurz weicheres Bild ist meist erträglicher als abgehackte Sprache.
- Auf der echten Route und zur geplanten Uhrzeit testen.
Eine gute Fallback-Szene ist Teil der Sendung
Eine Fallback-Szene sollte nicht wie eine Fehlermeldung wirken. Sie gehört zum visuellen Konzept und erklärt kurz, was passiert. Möglich sind ein Standbild, ein ruhiger Loop oder eine Studioansicht. Eingesetzte Musik muss selbstverständlich geklärt sein.
Der Umschaltmechanismus sollte zwei Schwellen kennen: erst nach einigen Sekunden ohne verwertbares Signal auf den Fallback wechseln und erst nach mehreren stabilen Sekunden zurückschalten. Sonst entsteht bei einer flatternden Verbindung ein störendes Hin und Her. Mit Regie kann die Rückkehr manuell freigegeben werden; vollautomatische Setups müssen besonders gründlich getestet werden.
Wiederanlauf ohne zweite Sendung
Ein mobiler Encoder muss nach einem Netzwechsel selbstständig erneut verbinden können. Prüfe vor dem Einsatz:
- Bleibt der Streamschlüssel nach einem Reconnect gültig?
- Verbindet sich die App nach Funkloch oder Flugmodus automatisch neu?
- Erkennt der Ingest-Server den ursprünglichen Eingang wieder?
- Bleibt die Ausgabe zur Plattform bestehen?
- Wird die Aufnahme fortgesetzt?
- Was passiert, wenn nur Bild oder Ton zurückkehrt?
Ein aussagekräftiger Test ist bewusst unbequem: Stream starten, Verbindung für 20 bis 30 Sekunden trennen, wiederherstellen und prüfen, wie sauber Bild und Ton zurückkommen. Danach denselben Test mit mehreren kurzen Unterbrechungen wiederholen.
Monitoring: Der eigene Bildschirm reicht nicht
Die Vorschau auf dem Smartphone zeigt, was der Encoder produziert – nicht zwingend, was beim Publikum ankommt. Eine zweite Perspektive ist daher wertvoll: Eine Regieperson beobachtet Plattform-Player, Server-Monitoring und Chat. Bei kleineren Produktionen helfen Warnungen für fehlenden Eingang, sinkende Bitrate oder ungewöhnlich viele Reconnects.
Zusätzlich sollten Akkustand, Temperatur, Datenvolumen, Audiopegel, serverseitige Aufnahme und die tatsächliche Ausgabe auf einem unabhängigen Gerät kontrolliert werden.
Der praktische Notfallplan
Technik wird nicht dadurch professionell, dass sie nie ausfällt. Professionell ist, wenn der Ausfall vorgesehen ist.
Vor dem Stream
- Route ablaufen und Problemzonen markieren.
- Mobilfunk zu unterschiedlichen Zeiten testen.
- Encoder, Ingest und Plattform als gesamte Kette proben.
- Fallback-Szene und Wiederverbindung prüfen.
- Geräte laden, Kühlung bedenken und Ersatzkabel einpacken.
Während des Streams
- Bitrate, Paketverlust und Temperatur beobachten.
- In schwierigen Bereichen Tempo und Kamerabewegung reduzieren.
- Bei längeren Störungen transparent kommunizieren.
- Nicht gleichzeitig Technik reparieren und sich unsicher im Verkehr bewegen.
Nach dem Stream
- Server- und Encoder-Protokolle auswerten.
- Zeitpunkt und Ort der Abbrüche dokumentieren.
- Fallback-Dauer und Wiederanlauf kontrollieren.
- Einstellungen erst nach einem reproduzierbaren Test ändern.
Fazit
Ein stabiler IRL-Livestream entsteht nicht durch einen einzelnen Trick. Entscheidend ist eine Kette aus realistischer Bitrate, fehlertolerantem Transport, einem erreichbaren Ingest-Server, einer durchdachten Fallback-Szene und einem getesteten Wiederanlauf. Wer zusätzlich eine unabhängige Kontrolle einplant, verwandelt ein Funkloch von einem Sendungsende in eine kurze, beherrschbare Unterbrechung.
