Standard HLS and DASH trade latency for resilience: a player buffers several full segments before playing, which on a six-second ladder means 15–30 seconds behind the source. Low-latency variants keep the same adaptive machinery but deliver media in smaller pieces and let the player fetch before a segment is complete, bringing glass-to-glass delay down to roughly 2–4 seconds.
The two low-latency formats
- LL-HLS — HLS with partial segments and blocking playlist reloads. The playlist advertises parts of the current segment, and the player can request them as they appear.
- LL-DASH — DASH with chunked CMAF and low-latency segment addressing. The MPD points at a segment that is still being written, and the player reads it progressively.
Both depend on CMAF fragmented segments so the same bytes can be delivered chunk by chunk and, ideally, shared with a standard-latency manifest for clients that cannot handle low latency.
How the latency comes out
| Mechanism | What it removes |
|---|---|
| Chunked transfer | Waiting for a full segment before starting to send |
| CMAF partial segments | Whole-segment buffering at the player |
| Blocking playlist reload | Fixed polling interval that adds a segment of delay |
| Preload hints | The extra round trip before requesting the next part |
| Short parts (0.2–0.5s) | Encoding and packaging pipeline buffering |
The pipeline also contributes: encoder lookahead, packager batching, and origin write delay each add time that no player setting can recover. Measure glass-to-glass, not player-reported latency, or you will optimise the wrong segment of the path.
Blocking reloads and preload hints
A blocking playlist reload is an HTTP request the player makes that the server holds open until the playlist changes, instead of the player polling on a timer. This removes a fixed poll interval from the critical path. Preload hints (EXT-X-PRELOAD-HINT in HLS, analogous signalling in DASH) tell the player the URL of the next part before it appears, so the request is already in flight when the bytes arrive. Together they shave whole round trips and are the difference between “low latency” and “slightly lower latency”.
The RFC 9317 cache-poisoning risk
RFC 9317 covers low-latency streaming and names a specific danger: truncated-segment cache poisoning. With chunked delivery, an edge or intermediary can cache a partial object, or a client can abort a chunked response mid-body. If the incomplete body is stored and later served as if complete, every subsequent viewer receives a corrupt segment. Defences:
- Do not cache incomplete responses; only store an object once it is fully received and validated.
- Use strong validators and treat partial objects as distinct from complete ones.
- Keep chunked and non-chunked representations in separate cache entries so a standard-latency request never reads a partially written low-latency object.
- Verify
Cache-Status(RFC 9211) andCDN-Cache-Control(RFC 9213) behaviour end to end, and watch for cache loops (RFC 8586).
When low latency is worth it
Low latency adds encoder pressure, more requests, more cache churn, and stricter origin requirements. It is worth it for interactive live — cams, auctions, chat-synchronised shows — where seconds of delay break the experience. For VOD it buys nothing. For passive live, standard segment latency is cheaper and more resilient.
Where AdultInfra fits
AdultInfra designs low-latency paths for live-cam and interactive adult platforms, from ingest through chunked delivery and cache safety, and measures the result glass-to-glass. See Live cam CDN and Live cam site for the full picture, then contact us to test a low-latency slice.