Classic HLS with 6-second segments and a three-segment player buffer sits 18–30 seconds behind the camera. CMAF chunked encoding combined with Low-Latency HLS (LL-HLS) pulls that to 2–5 seconds glass-to-glass by publishing 200–500 ms partial segments as the encoder produces them, before the parent segment is closed. The cost is paid in request volume and proxy discipline: per-viewer HTTP request rate rises roughly 10–20x, and every hop between packager and player must forward bytes as they arrive instead of buffering complete objects. Most failed low latency streaming rollouts fail on that second point, not on the encoder.
Segment-based delivery has a structural floor: nothing can be requested until it is fully written. A 6-second segment therefore adds at least 6 seconds of encoder-side latency, plus whatever the player holds in buffer. CMAF changes the unit of publication. A CMAF track is a sequence of fragments, and each fragment can be split into chunks (movie fragment box plus media data box) that are independently decodable in sequence and written the moment their frames are encoded.
LL-HLS exposes those chunks to the player as Partial Segments, declared with EXT-X-PART entries in the media playlist alongside the conventional EXTINF segment lines. Two mechanisms do the heavy lifting. Blocking playlist reload lets the player request the playlist at a specific media sequence and part index, and the server holds the response open until that part exists, removing the poll interval. Preload hints (EXT-X-PRELOAD-HINT) let the player issue the request for the next part before it exists, so the response streams out the instant the encoder emits it.
Assumptions for the table: 4-second segments, 333 ms parts, a 2-second GOP, a single-region encoder, and a player configured to PART-HOLD-BACK of three parts. Values are typical ranges observed in 2025–2026 deployments, not a single measurement.
| Stage | Contribution | What controls it |
|---|---|---|
| Capture, encode, chunk close | 350–600 ms | Part target duration, lookahead, B-frames |
| Packaging and publish to origin | 50–200 ms | Whether the packager writes parts as separate objects or byte ranges |
| Origin to edge, first byte | 40–150 ms | Shield distance, keep-alive reuse, TLS session reuse |
| Edge buffering penalty | 0 ms or +1 full part | Whether the proxy relays chunked responses or waits for the complete object |
| Player hold-back buffer | 1.0–2.0 s | PART-HOLD-BACK, ABR aggressiveness, rebuffer tolerance |
| Decode and render | 80–150 ms | Device decoder pipeline depth |
The single most important conclusion: the player's hold-back buffer, not the network, dominates the budget once CMAF chunked encoding is in place, and a proxy that buffers whole objects silently adds an entire part duration back.
Low-Latency HLS, defined in the second edition of the HLS specification and shipping widely since 2020, reduces live latency from the 18–30 seconds typical of 6-second-segment HLS to 2–5 seconds by delivering CMAF chunks as 200–500 ms partial segments; in 2026 production deployments that reduction is accompanied by a 10–20x increase in HTTP requests per viewer, because each part triggers both a media fetch and a blocking playlist response.
That request math is worth doing explicitly. With 4-second segments and 333 ms parts, one viewer consuming one video rendition plus one audio track generates about 12 part requests and 12 blocking playlist responses per 4 seconds, roughly 12 requests per second, against 0.6–0.7 requests per second for the classic 6-second-segment case. At 100,000 concurrent viewers that is over a million requests per second, and a large fraction of them are long-lived open connections waiting for a part to exist.
Three CDN behaviors decide whether that works:
Cacheability follows from how the packager writes parts. Separate part objects cache cleanly with short TTLs. Byte-range parts of an incomplete parent segment require the edge to serve ranges of an object it does not yet have in full, which many configurations handle by falling back to a pass-through fetch per range.
A minimal LL-HLS media playlist carries these directives, values shown for 4-second segments and 333 ms parts:
EXT-X-VERSION set to 9 or higher.
EXT-X-PART-INF with PART-TARGET set to 0.334.
EXT-X-SERVER-CONTROL with CAN-BLOCK-RELOAD set to YES, PART-HOLD-BACK set to 1.002 (three part targets), and CAN-SKIP-UNTIL set to 24.0 for delta playlist updates.
EXT-X-PART entries with DURATION, URI, and INDEPENDENT set to YES on parts that begin with a keyframe.
EXT-X-PRELOAD-HINT of type PART pointing at the part not yet produced.
EXT-X-PROGRAM-DATE-TIME on each segment, which is the only practical way to measure end-to-end latency later.
Delta playlist updates matter more than they look. On a long DVR window, a full playlist re-sent per part can reach 100–300 KB; CAN-SKIP-UNTIL trims the repeated history and cuts playlist bytes by 60–90 percent, which is a direct saving on both egress and parse time on low-end devices.
Adaptive bitrate estimation degrades with small parts. Throughput measured over a 333 ms transfer is noisy, and a player that switches on that signal oscillates. Practical implementations smooth over several parts, which slows reaction to genuine congestion and turns some switch decisions into rebuffers.
Latency and rebuffer rate trade against each other directly. Dropping PART-HOLD-BACK from three parts to two removes about 330 ms of latency and measurably raises stall rate on mobile networks with 2 percent packet loss. Pick the target from your audience mix, not from a demo on office wiring.
Observability is the weakest part of the stack. Edge access logs record part requests as ordinary 200s, so a blocking playlist request held for 900 ms looks identical to a slow origin. You need to separate intentional hold time from unintentional wait, which usually means instrumenting the player with EXT-X-PROGRAM-DATE-TIME deltas and correlating against edge time-to-first-byte per part. If you are shortlisting CDNs, chunked relay and request collapsing are configuration questions to settle during onboarding rather than assumptions, and it is worth reviewing the edge features that matter for low latency streaming before you commit a live event to a platform.
Worth it: betting, auctions, interactive sports, game shows, second-screen experiences, anything where a viewer can compare your stream against another signal. Two seconds of latency is a product feature there.
Not worth it: linear channels, VOD-adjacent replays, and long-tail events where the audience never sees a reference clock. You will pay a 10–20x request multiplier, tighter operational tolerances, and a higher rebuffer floor for latency nobody notices. A well-tuned 4-second-segment HLS profile at 8–10 seconds of latency is cheaper to run and easier to debug.
Take one channel, cut segments to 4 seconds with 333 ms parts, publish through your current CDN unchanged, and measure two things over a 30-minute window: p50 and p95 player latency from EXT-X-PROGRAM-DATE-TIME, and origin requests per second for the busiest media playlist. If latency lands above 5 seconds with healthy time-to-first-byte, you have a buffering proxy. If origin request rate scales with viewers, you have no request collapsing. Both are configuration problems with known fixes, and both are far cheaper to find in a test than during a final.