The Latency Spectrum in Video Delivery
Different streaming use cases require drastically different latencies:
- Standard Live (HLS/DASH): 15–30 seconds latency. High CDN cacheability, ideal for sports broadcasts.
- Low-Latency HLS (LL-HLS) / CMAF: 2–4 seconds latency. Good for interactive sports and Twitch-style gaming.
- Ultra-Low Latency (WebRTC): < 500 milliseconds. Required for video conferences (Zoom, Google Meet) and interactive bidding.
WebRTC vs. HTTP Streaming
WebRTC commonly carries SRTP media over UDP selected through ICE, but it can fall back through TURN over TCP or TLS when networks block UDP. Receivers use jitter buffers, and implementations may request selected retransmissions with NACK while congestion control trades quality against delay; no transport guarantees conversation latency. A peer-to-peer mesh is practical only for small calls. An SFU is an alternative topology that receives each participant's stream and forwards selected layers, while very large passive audiences often use HTTP-based low-latency streaming.
Worked example: three latency budgets
- Classic HLS: encoder and packaging about 2 s, one full 6 s segment must finish before it is published, the CDN adds about 1 s, and the player buffers 3 segments (18 s). Total roughly 20 to 30 s.
- Low-Latency HLS: segments are split into partial segments of about 200 to 500 ms; the player uses blocking playlist reloads and preload hints to request parts as soon as they exist, and keeps a buffer of a few parts. Total roughly 2 to 5 s.
- WebRTC: capture about 30 ms, encode about 20 ms, network 50 to 150 ms, jitter buffer 50 to 100 ms, decode and render about 20 ms. Total roughly 200 to 350 ms, with no segment waiting at all.
Group call topology
In a 10-person mesh, each participant sends 9 copies of a 1.5 Mbit/s stream: 13.5 Mbit/s of upload, which most home connections cannot sustain. With an SFU, each participant uploads once (or 3 simulcast layers, for example 1.5, 0.5 and 0.15 Mbit/s) and the SFU forwards the right layer to each receiver based on their bandwidth and window size. An MCU mixes streams into one, saving client bandwidth at a high server CPU cost.
Protocol comparison
| Protocol | Typical latency | Audience scale | CDN cacheable | Typical use |
|---|---|---|---|---|
| HLS or DASH | 10 to 30 s | Tens of millions | Yes | Sports and events broadcast |
| LL-HLS or low-latency DASH (CMAF chunks) | 2 to 5 s | Millions | Yes, with CDN support for blocking requests | Interactive streams, Twitch-style |
| WebRTC via SFU | under 0.5 s | Thousands per SFU cluster, more with cascading | No | Calls, auctions, betting, co-streaming |
| RTMP, SRT or WHIP ingest | Contributes 0.1 to 2 s | One publisher | Not applicable | Getting video from the streamer to the platform |
How real systems do it
- Disney+ Hotstar served tens of millions of concurrent cricket viewers over HTTP streaming through multiple CDNs, pre-scaling capacity ahead of matches.
- Amazon IVS offers low-latency HLS for large audiences and separate WebRTC-based real-time stages for interactive guests, reflecting the same split.
- WHIP and WHEP are IETF work that standardize WebRTC ingest and playback signalling over HTTP, making WebRTC easier to plug into streaming pipelines.