← Zurück zum Help-Center
FAQ 4 min Lesezeit

Was ist SRTLA? — SRTLA vs. RTMP erklärt

Warum SRTLA der beste Transport für IRL-Streaming ist — Vergleich mit RTMP.

Was ist SRTLA?

SRTLA steht für Secure Reliable Transport Link Aggregation. Es ist ein Protokoll, das mehrere Internet-Verbindungen (LTE-Modems, WLAN, Ethernet) zu einem einzigen logischen Uplink bündelt und Pakete über alle Pfade parallel sendet. Serverseitig werden die Pakete wieder in die richtige Reihenfolge gebracht.

Entwickelt von BELABOX für IRL-Streaming — also mobiles Streamen, wo einzelne Netze oft schwächeln.

Warum SRTLA statt RTMP?

RTMP (Real-Time Messaging Protocol) ist 2005 aus der Flash-Ära hervorgegangen. Es läuft über TCP und wurde nie fürs mobile Internet gebaut.

TCP vs. UDP

  • TCP (RTMP) garantiert die Reihenfolge und retried Pakete automatisch. Problem: Head-of-line-Blocking. Wenn ein einzelnes Paket im Mobilfunk verloren geht, wartet alles danach — dein Stream friert.
  • UDP (SRT/SRTLA) schickt einfach weiter. Pakete können kurzzeitig ausser Reihenfolge ankommen, aber der Stream bleibt lebendig. SRT kompensiert dafür mit einem Jitter-Buffer auf Server-Seite.

Packet Loss

Mobilfunk hat typischerweise 1-5% Packet Loss. TCP/RTMP retried jedes verlorene Paket -> Latenz explodiert, oft auf 10+ Sekunden, bis der Stream kollabiert.

SRT erlaubt konfigurierbaren Retry-Window (typisch 2000ms Latency) — verlorene Pakete werden nur retried, wenn sie in dieser Zeit noch ankommen können. Der Rest: weg, aber egal.

Link-Aggregation

SRTLA's Killer-Feature: parallele Nutzung mehrerer Modems.

  • Belabox: 2x LTE + 1x WLAN = 3 Links gleichzeitig
  • Gesamtbandbreite = Summe der Links
  • Wenn ein Link komplett stirbt (z.B. du gehst in ein Funkloch), übernehmen die anderen sofort

Mit RTMP müsstest du deinen Stream komplett auf einem Link pinnen — Link stirbt = Stream stirbt.

Vergleichs-Tabelle

| Feature | RTMP | SRT | SRTLA | |---------|------|-----|-------| | Transport | TCP | UDP | UDP (mehrfach) | | Typische Latenz | 3-6s | 1-3s | 1-3s | | Verhalten bei Packet Loss | Freeze | Jitter-tolerant | Jitter-tolerant | | Multi-Link | Nein | Nein | Ja (Bonding) | | Encryption | Nein (nur RTMPS) | AES-128/256 | AES-128/256 | | Firewall-Freundlich | Sehr (80/443/1935) | Mittel (9898 UDP) | Mittel | | Fürs IRL geeignet | Schlecht | Gut | Ideal |

Wann solltest du RTMP nehmen?

  • Home-Setup mit Glasfaser — dein Netz ist stabil, SRT bringt null Vorteil
  • Firewall/ISP blockt UDP — RTMP läuft überall
  • Encoder unterstützt nur RTMP — viele ältere Hardware-Encoder (z.B. TriCaster) haben kein SRT

Wann solltest du SRT nehmen?

  • Mobilfunk/LTE als Uplink
  • Niedrige Latenz wichtig (Interaktiver Chat, Q&A)
  • Fluktuierendes Netz (Reise, Event, Sportveranstaltung)

Wann SRTLA?

  • Mobile IRL mit mehreren Modems
  • Professional Event-Broadcast mit Dual-ISP-Redundanz
  • Überall wo ein einzelner Link nicht genug Bandbreite hat

FizzyPeak unterstützt alle drei

FizzyPeak hat nativen SRTLA-Empfänger (nicht über ein externes Relay — wir haben das selbst gebaut). Das heisst:

  • Keine extra Latenz durch Zwischen-Relay
  • Direktes Feedback an deinen Encoder (Link-Stats, RTT)
  • Ingest-Endpoint: ingest.fizzypeak.stream:9898 für SRT+SRTLA

Für RTMP: rtmp://ingest.fizzypeak.stream/live.

Praktisch: Latency-Einstellungen

Die SRT/SRTLA-Latency ist der Jitter-Buffer auf Server-Seite. Zu niedrig -> Stream bricht. Zu hoch -> Viewer warten länger.

  • 1000ms — Home-Glasfaser, stabiles WLAN
  • 2000ms — Standard Stadt-LTE (empfohlen)
  • 4000ms — Reise, US-Roaming, instabile 5G
  • 8000ms — Satellit, richtig schlechtes Netz

Die Latency wird in der URL gesetzt: ?latency=2000. Sie betrifft nur das Ingest-Glied — deine Viewer sehen keinen Unterschied, weil YouTube/Twitch eigene Buffer haben.

Kernpunkt: Wenn du IRL streamst -> SRT oder SRTLA. RTMP nur als absoluter Fallback.

Noch Fragen? Öffne das Dashboard oder schreib im Discord #support.