Live-Streaming unter einer Sekunde: warum 5 s einfach und 1 s schwer ist

Im Jahr 2026 ist Live-Gehen ein gelöstes Problem. Sie laden OBS herunter, richten es auf YouTube, Twitch, Kick oder Facebook Live, klicken auf Start Streaming — und innerhalb von etwa zwanzig Sekunden ist Ihr Video auf der anderen Seite der Welt. Was die meisten nicht sehen, ist wie viel Internet zusammenarbeiten muss, damit das funktioniert, und warum diese zwanzig Sekunden auf unter eine zu drücken das härteste Problem im Live-Video ist.

Der einfache Teil: Live-Streaming im Jahr 2026

Die Streaming-Welt steht auf einer Handvoll großer Plattformen und einer dominanten Produzenten-App:

• YouTube Live — typische Glass-to-Glass-Latenz 10–30 s im Normal-Modus, 5–10 s in Low Latency, 2–5 s in Ultra-Low Latency.
• Twitch — etwa 5–8 s mit aktiviertem "Low Latency", 10–15 s ohne.
• Kick — ähnlich wie Twitch, 3–8 s unter guten Bedingungen.
• Facebook Live — 10–20 s.

Auf der Producer-Seite fast immer OBS Studio — kostenlos, Open Source und de-facto-Industriestandard. OBS erfasst Webcam, Bildschirm, Mikrofone und Audio-Mixer, encodiert das Signal mit x264 oder NVENC und schiebt es über RTMP (Real-Time Messaging Protocol) an die Plattform. RTMP ist ein Flash-Protokoll von 1997, das einfach nicht sterben will — weil es funktioniert: TCP-basiert, chunked, zuverlässig, gut genug für einseitigen Ingest.

Wie Ihre Frames beim Zuschauer landen

Alles oben läuft über ungefähr dieselbe Pipeline:

┌─────────┐  RTMP   ┌────────┐  transcode  ┌─────────┐  HLS/DASH  ┌────────┐
│   OBS   │ ──────▶ │ Ingest │ ──────────▶ │ Package │ ─────────▶ │  CDN   │
│ Encoder │         │ Server │             │ + Chunk │            │  Edge  │
└─────────┘         └────────┘             └─────────┘            └───┬────┘
                                                                      │
                                                           ┌──────────▼────────┐
                                                           │  Player (HLS.js)  │
                                                           │  5–30 s Rückstand │
                                                           └───────────────────┘

1. Ingest. OBS publiziert RTMP an den nächsten Ingest-Node.
2. Transcode. Der Ingest-Server encodiert auf mehrere Bitraten (1080p / 720p / 480p).
3. Segmentieren & Packaging. Jede Variante wird in kleine Chunks zerlegt — meist 2–6 s .ts oder .m4s-Dateien — und in ein HLS- oder MPEG-DASH-Manifest verpackt.
4. Cache. Die Chunks propagieren durch ein CDN (Cloudflare, Akamai, Fastly…) und werden von Zuschauern bei Bedarf abgerufen.
5. Playback. Der Browser fügt die Chunks mit hls.js oder nativem MSE wieder zu einem durchgehenden Video zusammen.

Warum 3–5 Sekunden einfach sind

Die HLS/DASH-Pipeline ist schön, weil sie einfach HTTP ist. CDNs können HTTP längst in gigantischem Maßstab cachen — ein einzelner Stream fächert sich trivial auf eine Million Zuschauer auf. Mit LL-HLS (Low-Latency HLS) und CMAF Chunked Transfer sinkt die Segmentdauer auf ~200 ms und die Gesamtlatenz landet bei 3–5 Sekunden. Für einen Vlog, ein Fußballspiel oder ein Konzert völlig ausreichend.

Warum eine Sekunde schwer ist

Sub-Sekunden-Latenz zerbricht das gesamte HTTP-Caching-Modell. In diesem Budget können Sie sich nicht leisten:

• 2–6 Sekunden Buffer auf der Player-Seite (Standard-HLS).
• Zu warten, bis ein Segment fertig geschrieben ist, bevor es gecached wird.
• TCP-Handshake, TLS-Negotiation und HTTP-Header für jeden Chunk zu tolerieren.

Um end-to-end unter eine Sekunde zu kommen — Live-Auktionen, iGaming, Interactive Sports, Telemedizin — muss HTTP-basiertes Segment Delivery raus und durch einen Push-basierten UDP-Transport ersetzt werden. In der Praxis heißt das WebRTC:

• UDP (SRTP) statt TCP/HTTP — kein Head-of-Line Blocking.
• SDP-Negotiation einmal am Session-Start — keine wiederholten Handshakes.
• Codec-Flexibilität — VP8 / VP9 / H.264 / AV1 mit FEC und NACK-basiertem Recovery.
• Jitter-Buffer von 50–150 ms statt 2–6 Sekunden.

Der Haken: WebRTC wurde für 1:1-Anrufe entworfen. Es auf Zehntausende Zuschauer auszufächern verlangt einen eigenen SFU- (Selective Forwarding Unit) Mesh, sorgfältige Bandbreitenschätzung, regionale PoPs und eine Signalisierungsschicht, die das Ganze orchestriert. Nichts davon gibt es von der Stange.

Workbox Stream: unter einer Sekunde, One-to-Many, im großen Maßstab

Genau hier kommt Workbox Stream ins Spiel. Unsere One-to-Many-WebRTC-Broadcast-Plattform, gebaut für die Fälle, in denen jede Sekunde Verzögerung Geld oder Vertrauen kostet:

• Glass-to-Glass-Latenz unter einer Sekunde — typisch 400–800 ms je nach Netzwerk des Zuschauers.
• Tausende gleichzeitige Zuschauer pro Stream über einen SFU-Mesh mit regionalen Edge-PoPs.
• Live-Reaktionen, Chat und Umfragen über denselben Low-Latency-Data-Channel — kein zusätzliches WebSocket-Flickwerk.
• OBS-kompatibler Ingest (WHIP) neben nativem Browser-Publishing — Producer behalten ihren Workflow.
• Recording und VOD-Export out of the box — derselbe Low-Latency-Stream ist gleichzeitig Ihr Archiv.

Wenn Sie ein Auktionshaus, ein Live-Wett-Produkt, einen Remote-Surgery-Pilot oder irgendein Event betreiben, bei dem "ein paar Sekunden zu spät" nicht akzeptabel ist — melden Sie sich. Die Erstberatung ist unverbindlich und kostenlos.