Inhalt dieses Guides
RTMP ist als Ingest-Protokoll weit verbreitet, SRT wurde dagegen für robuste Low-Latency-Übertragung über problematische Netze entwickelt. Für IRL können beide an unterschiedlichen Stellen derselben Pipeline sinnvoll sein.
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.
Bei IRL Streaming werden SRT und RTMP häufig so behandelt, als müsse man sich grundsätzlich für eines der beiden Protokolle entscheiden. In der Praxis können sie unterschiedliche Aufgaben übernehmen: SRT kann beispielsweise den schwierigen Weg vom mobilen Encoder zu einem eigenen Server absichern, während der Server anschließend per RTMP oder RTMPS an eine Plattform weiterleitet.
RTMP: der etablierte Ingest-Weg
RTMP ist seit vielen Jahren ein verbreitetes Protokoll, um Livevideo an Streamingplattformen zu senden. Viele Encoder und Plattformen unterstützen es direkt. YouTube dokumentiert RTMP/RTMPS weiterhin als Eingangsprotokoll für Live-Encoder.
Der große Vorteil ist die Kompatibilität. Wenn ein Dienst nur einen Stream-Key und eine RTMP(S)-URL erwartet, ist der Workflow unkompliziert.
SRT: für schwierige Netzwerke entwickelt
SRT steht für Secure Reliable Transport. Das Open-Source-Projekt beschreibt SRT als Transportprotokoll für Livevideo mit geringer Latenz, das unter anderem auf Paketverlust, Jitter und schwankende Netzwerkbedingungen reagieren kann. Verlorene Pakete können innerhalb eines konfigurierten Zeitfensters erneut angefordert werden.
Warum Retransmission Latenz benötigt
Wenn ein Paket fehlt, braucht das System Zeit, um den Verlust zu erkennen, eine Wiederholung anzufordern und das Paket erneut zu empfangen. Genau deshalb ist SRT-Latenz nicht einfach ein unnötiger Puffer. Das konfigurierte Zeitfenster ist Teil des Kompromisses zwischen niedriger Verzögerung und Fehlerkorrektur.
Zu wenig Puffer lässt weniger Zeit für Wiederholungen. Zu viel Puffer macht die Übertragung robuster, erhöht aber die Verzögerung. Die optimale Einstellung hängt von Round-Trip-Time, Jitter und Verlust auf dem realen Pfad ab.
Typischer IRL-Workflow mit SRT
- Mobiler Encoder erzeugt den Stream.
- SRT transportiert ihn über Mobilfunk zu einem erreichbaren Server oder Cloud-Endpunkt.
- Dort wird das Signal gegebenenfalls verarbeitet oder neu verpackt.
- Der Ausgang geht per von der Zielplattform unterstütztem Protokoll weiter.
Dieser Aufbau kann sinnvoll sein, wenn die Zielplattform selbst kein SRT als direkten Ingest anbietet oder wenn du zwischen mobiler Übertragung und Plattform zusätzliche Kontrolle benötigst.
Vergleich
| Kriterium | RTMP/RTMPS | SRT |
|---|---|---|
| Plattform-Kompatibilität | sehr verbreitet | häufig über Zwischenserver |
| Paketverlust | weniger spezialisiert auf problematische Links | Retransmission und definierte Latenzmechanismen |
| Einrichtung | oft sehr einfach | mehr Parameter und Infrastruktur |
| IRL-Uplink | möglich | besonders interessant bei instabilen Netzen |
RTMPS statt unverschlüsseltem RTMP
Wenn eine Plattform RTMPS unterstützt, ist die verschlüsselte Variante für die Übertragung zum Plattform-Ingest vorzuziehen. YouTube empfiehlt in seiner aktuellen Hilfe ausdrücklich RTMPS.
Welches Protokoll solltest du wählen?
Wenn du gerade erst mit IRL beginnst und direkt aus einer unterstützten App an Twitch oder YouTube sendest, ist ein zusätzlicher SRT-Server möglicherweise unnötige Komplexität. Wenn du dagegen wiederkehrende Mobilfunkprobleme analysierst, einen eigenen Relay-Server verwendest oder Redundanz brauchst, wird SRT wesentlich interessanter.
