Wenn du auf Instagram live gehst und jemand einen Kommentar schreibt, siehst du ihn erst 5–10 Sekunden später — obwohl du beide zur selben Zeit aktiv bist. Das ist kein Bug. Es ist eine direkte Konsequenz des Protokolls, das Instagram verwendet. Hier ist der Unterschied.
RTMP — der älteste Standard
RTMP (Real-Time Messaging Protocol) wurde von Adobe für Flash entwickelt und ist heute noch der Standard für das Einspeisen von Streams in Plattformen. OBS, Larix, alle Streaming-Apps senden per RTMP an den Ingest-Server von YouTube oder Twitch.
RTMP selbst hat eine Latenz von 1–5 Sekunden. Das Problem entsteht danach: Plattformen wandeln RTMP-Streams intern in HLS oder DASH um — und das kostet Zeit.
HLS — für Skalierung gebaut, nicht für Echtzeit
HLS (HTTP Live Streaming) von Apple ist der Verteilungsstandard für fast alle großen Streaming-Plattformen. Das Prinzip: Das Audio/Video wird in kleine Segmente geschnitten (typisch 2–10 Sekunden), auf einem CDN gespeichert und vom Player sequenziell heruntergeladen.
Das ist extrem skalierbar — Millionen Zuschauer gleichzeitig, weltweit verteilt, ohne dass der Original-Server überlastet wird. Aber der Puffer ist unvermeidlich: Der Player muss mindestens 2–3 Segmente puffern bevor er abspielt. Ergebnis: 6–30 Sekunden Latenz, je nach Plattform und Konfiguration.
WebRTC — Echtzeit durch anderes Grundprinzip
WebRTC (Web Real-Time Communication) verwendet einen völlig anderen Ansatz: kein Segmentieren, kein CDN-Puffer. Audio und Video werden als kontinuierlicher UDP-Datenstrom direkt übertragen — ähnlich wie ein Telefongespräch.
Wenn ein Paket verloren geht, wird es nicht erneut angefordert (das würde Latenz erzeugen) — stattdessen interpoliert der Decoder oder nutzt Fehlerkorrektur-Daten die mitgesendet wurden. Das Ergebnis: 150–500 ms Ende-zu-Ende-Latenz. Live im echten Sinne — nicht Live mit 10 Sekunden Verzögerung.
Warum nicht alle Plattformen WebRTC nutzen
Skalierbarkeit. HLS kann denselben Stream an Millionen Nutzer gleichzeitig ausliefern, weil ein CDN die Last übernimmt. WebRTC erfordert eine direkte Verbindung zwischen Broadcaster und jedem Listener — oder einen Media-Server (wie LiveKit) der zwischen beiden vermittelt. Das ist aufwändiger zu betreiben, aber für Szenarien bis zu ein paar hundert gleichzeitigen Zuhörern absolut machbar — und das ist die Zielgruppe von RGBeats.
Zusammenfassung
Instagram und YouTube haben 10+ Sekunden Delay weil HLS für Skalierbarkeit optimiert ist, nicht für Echtzeit. RGBeats hat unter 500 ms weil WebRTC für Echtzeit gebaut wurde. Wer tausend Kommentare pro Sekunde erwartet, braucht HLS. Wer echte Live-Momente will, braucht WebRTC.