Sub-second live streaming: why 5 seconds is easy and 1 second is hard

In 2026, going live is a solved problem. You download OBS, point it at YouTube, Twitch, Kick or Facebook Live, hit Start Streaming — and within about twenty seconds your video is on the other side of the world. What most people don't realise is just how much of the internet has to cooperate to make that happen, and why shaving those twenty seconds down to under one is the hardest problem in live video.

The easy part: live streaming in 2026

The streaming world is built on a small set of big platforms and one dominant producer app:

• YouTube Live — typical glass-to-glass latency 10–30 s in Normal mode, 5–10 s in Low Latency, 2–5 s in Ultra-Low Latency.
• Twitch — around 5–8 s with "Low Latency" enabled, 10–15 s without.
• Kick — similar to Twitch, 3–8 s in good conditions.
• Facebook Live — 10–20 s.

The producer end is almost always OBS Studio — free, open-source, and the de-facto industry standard. OBS captures your webcam, screen, microphones and audio mixer, encodes the combined feed with x264 or NVENC, and pushes it to the platform over RTMP (Real-Time Messaging Protocol). RTMP is a 1997-era Flash protocol that refuses to die, because it works: TCP-based, chunked, reliable, good enough for one-way ingest.

How your frames actually reach a viewer

Everything above rides on roughly the same pipeline:

┌─────────┐  RTMP   ┌────────┐  transcode  ┌─────────┐  HLS/DASH  ┌────────┐
│   OBS   │ ──────▶ │ Ingest │ ──────────▶ │ Package │ ─────────▶ │  CDN   │
│ encoder │         │ server │             │ + chunk │            │  edge  │
└─────────┘         └────────┘             └─────────┘            └───┬────┘
                                                                      │
                                                           ┌──────────▼────────┐
                                                           │  player (HLS.js)  │
                                                           │   5–30 s behind   │
                                                           └───────────────────┘

1. Ingest. OBS publishes RTMP to the nearest ingest node.
2. Transcode. The ingest server re-encodes to multiple bitrates (1080p / 720p / 480p).
3. Segment & package. Each rendition is chopped into small chunks — typically 2–6 second .ts or .m4s files — and wrapped in an HLS or MPEG-DASH manifest.
4. Cache. Those chunks propagate through a CDN (Cloudflare, Akamai, Fastly…) and get pulled by viewers on demand.
5. Playback. The browser uses hls.js or native MSE to stitch the chunks back into a continuous video.

Why 3–5 seconds is easy

The HLS/DASH pipeline is beautiful because it's just HTTP. CDNs already know how to cache HTTP at massive scale, so a single stream can fan out to a million viewers trivially. With LL-HLS (Low-Latency HLS) and CMAF chunked transfer, segment duration drops to ~200 ms and total latency lands in the 3–5 second range. That's good enough for a vlog, a football match, a concert.

Why 1 second is hard

Sub-second latency breaks the entire HTTP-caching model. At that budget you cannot:

• Buffer 2–6 seconds on the player side (standard HLS).
• Wait for a segment to finish writing before caching it.
• Tolerate a TCP handshake, TLS negotiation and HTTP headers for every chunk.

To go under one second end-to-end — think live auctions, iGaming, interactive sports, telemedicine — you have to rip out HTTP-based segment delivery and replace it with a pushed UDP transport. In practice that means WebRTC:

• UDP (SRTP) instead of TCP/HTTP — no head-of-line blocking.
• SDP negotiation once at session start — no repeated handshakes.
• Codec agility — VP8 / VP9 / H.264 / AV1 with FEC and NACK-based recovery.
• Jitter buffer of 50–150 ms instead of 2–6 seconds.

The catch: WebRTC was designed for 1-to-1 calls. Fanning it out to tens of thousands of viewers requires a custom SFU (Selective Forwarding Unit) mesh, careful bandwidth estimation, per-region PoPs, and a signalling layer that can orchestrate the whole thing. None of this is off-the-shelf.

Workbox Stream: sub-second, one-to-many, at scale

That's where Workbox Stream comes in. It's our one-to-many WebRTC broadcast platform, purpose-built for the use cases where every second of lag costs you money or trust:

• Glass-to-glass latency under one second — typically 400–800 ms depending on the viewer's network.
• Thousands of concurrent viewers per stream via an SFU mesh with regional edge PoPs.
• Live reactions, chat and polls over the same low-latency data channel — no extra WebSocket duct-tape.
• OBS-compatible ingest (WHIP) alongside native browser publishing — your producers keep their existing workflow.
• Recording and VOD export out of the box, so the same low-latency stream doubles as your archive.

If you're running an auction house, a live-betting product, a remote-surgery pilot, or any event where "a few seconds late" is unacceptable — get in touch. The first consultation is free.