Low-Latency Streaming: HLS vs. DASH vs. WebRTC

By now we've covered message queues, pub/sub, and WebRTC's signaling and NAT-traversal dance as separate pieces of real-time infrastructure. Video streaming pulls several of those ideas together into one very concrete engineering decision: when a product needs to get video from one place to many eyeballs, which protocol actually does that job? The honest answer is "it depends on how live 'live' needs to be" — and the three main options, HLS, DASH, and WebRTC, sit at very different points on the same underlying trade-off between latency and cost-to-scale.

HLS and DASH: the same idea, two vendors

HTTP Live Streaming (HLS, from Apple) and Dynamic Adaptive Streaming over HTTP (DASH, an open MPEG standard) are, under the hood, the same idea implemented twice. A video is encoded at several quality levels and sliced into short chunks — historically 6-10 seconds each. A manifest file (an .m3u8 playlist for HLS, an .mpd manifest for DASH) lists those chunks, and the player downloads them one after another over plain HTTP, switching between quality levels on the fly as bandwidth changes. That's the "adaptive bitrate" part: a viewer on a train tunnel drops to 480p automatically, a viewer on fiber climbs to 4K, and neither needs a special protocol to make that happen.

The reason this design won is boring in the best possible way: a chunk of video over HTTP looks exactly like any other static file to the network. It can sit behind an ordinary CDN edge cache, get replicated to hundreds of points of presence, and served to millions of concurrent viewers using the same infrastructure that serves images and JavaScript bundles. You don't provision anything per-viewer — you just cache a handful of files and let the CDN do what CDNs already do well. That's an enormous, almost accidental advantage: streaming an event to ten viewers and streaming it to ten million viewers costs the same per-viewer, because caching scales that way and per-connection routing doesn't.

The cost of that design is latency. Before a viewer sees anything, the encoder has to finish a chunk, the packager has to write it and update the manifest, the CDN has to fetch and cache it, and the player has to download several chunks into a buffer before it starts playing — insurance against a network hiccup causing a stall. Stack all of that up and traditional HLS/DASH commonly runs 6-30+ seconds behind the camera. For a two-hour movie, that number is irrelevant. For a live event, it's the reason your neighbor's cheer at a goal reaches you through the wall before it reaches you through the stream.

WebRTC: the opposite end of the spectrum

WebRTC takes the inverse trade-off. It was built for video calls, where sub-second, bidirectional latency isn't a nice-to-have — it's the entire product. Media flows over UDP-based RTP streams between peers (or, at any real scale, through a Selective Forwarding Unit that relays packets between participants), with no chunking, no manifest polling, and no multi-second buffer standing between capture and playback. Latency lands in the 200-500ms range, close enough to a phone call that a conversation feels natural.

That immediacy comes at a structural cost: WebRTC delivery isn't cacheable. Every viewer needs an active, stateful connection that terminates somewhere — a peer or an SFU — rather than a request a CDN edge can answer from a cached file. Fanning WebRTC out to a large one-to-many audience means running (and paying for) a fleet of SFUs that scales roughly with concurrent viewers, not with unique content. That's a completely different cost curve than HLS/DASH, and it's why nobody serves a stadium concert to five million viewers over raw WebRTC — the infrastructure bill would dwarf the CDN alternative for a latency improvement most of that audience doesn't need.

The middle ground: Low-Latency HLS and DASH

Low-Latency HLS (LL-HLS, Apple's extension) and Low-Latency DASH close most of the gap without abandoning the CDN model. The core trick is delivering partial segments instead of waiting for a whole chunk: the player can start fetching and rendering a segment while the encoder is still producing it, using HTTP chunked transfer encoding and shorter segment durations (often one second or less, versus HLS's traditional 6-10). Manifests update incrementally, and techniques like HTTP/2 push or blocking playlist requests let the player learn about a new chunk the instant it exists rather than polling for it.

The result lands around 2-5 seconds end to end — nowhere near WebRTC's sub-second figures, but a large improvement over classic HLS/DASH, and crucially still built on ordinary HTTP chunks that a CDN can cache. It's a genuine middle ground: most of the scaling economics of chunked streaming, with a latency profile that makes a live stream feel current rather than delayed.

Matching the protocol to the product

Once the trade-off is explicit, picking a protocol is really about answering one question: how much does this specific product need the seconds you'd save?

• Traditional HLS/DASH — video-on-demand, and most one-to-many live broadcasts where a delay of several seconds is simply invisible to the use case: movies and shows, most live sports and awards shows, conference livestreams. The audience watches, they don't interact against a shared clock, and the CDN economics make massive scale cheap.
• Low-Latency HLS/DASH — large-audience live events where "somewhat live" is good enough but a 20-second lag would visibly break the experience: auction-style shopping streams, live sports with a companion second screen (betting odds, social chatter) that shouldn't feel out of sync, breaking-news broadcasts. You keep most of the CDN-friendly scale while trimming latency down to a few seconds.
• WebRTC — genuinely interactive scenarios where sub-second round-trip time is the product, not a polish item: video calls and conferencing, live auctions where bidders react to each other in real time, interactive watch-and-bid or watch-and-vote streams, cloud gaming, remote-controlled hardware. Audiences here are typically smaller and more latency-sensitive, which is exactly where paying for per-viewer SFU infrastructure makes sense.

Plenty of real products end up using more than one of these at once — a live-shopping platform might run WebRTC for the host-to-producer feed where reaction time matters, and fan the final broadcast out to the audience over Low-Latency HLS, because the audience is watching, not negotiating a bid in real time.

The trade-off, restated

Strip away the acronyms and there's one underlying dial: how much latency are you willing to accept in exchange for how much cheaper you want each additional viewer to be. HLS and DASH sit at the cheap-per-viewer end by riding on cacheable HTTP and existing CDN infrastructure, and pay for it in seconds of delay. WebRTC sits at the low-latency end by giving every viewer a live, stateful connection, and pays for it in infrastructure that scales with viewer count instead of content. Low-Latency HLS/DASH is the compromise that keeps most of the CDN economics while shaving the delay down to a few seconds. There's no version of this stack that gives you sub-second latency and free-as-a-CDN scaling — picking the right protocol is really just picking which side of that trade-off your product can't live without.