Before LL-HLS, an HLS player could only fetch full segments — typically 2–6 seconds each. EXT-X-PART changes that. A media playlist that wants to support low-latency lists each in-progress segment's partial pieces using one EXT-X-PART tag per partial, with attributes DURATION (in seconds, fractional), URI (or BYTERANGE of the parent segment), and INDEPENDENT (true if the partial starts with a keyframe and is itself decodable).
The player reads the EXT-X-PART tags for the in-progress segment, fetches each partial as soon as it appears, and starts decoding before the parent segment is complete. Combined with EXT-X-PRELOAD-HINT (so the player knows the URL of the next partial before it exists) and blocking playlist reload (so the player can wait server-side for the next playlist update without polling), this brings glass-to-glass latency down to 2–5 seconds.
The Apple HLS Authoring Specification's recommended pattern is 1-second segments with 200 ms partials, giving 5 partials per segment. Each partial is a CMAF chunk in the underlying media. Operationally the partials are usually byte-range references into the parent segment (one HTTP file per segment, byte-range fetches for partials) — this keeps the cache footprint manageable and avoids the URL explosion of treating each partial as its own file.
The book · Volume 2 of 7
Video Streaming: A Complete Guide to Video Delivery: From Network Protocols and Transport to Ingest, HLS, and MPEG-DASH
EXT-X-PART is how LL-HLS cuts latency, but part duration, segment length and CDN behavior all have to line up. Volume 2 covers EXT-X-PART in detail: HLS and low-latency HLS, CMAF packaging, segment-based protocols and the glass-to-glass latency budget. Written by Nikolay Sapunov, CEO at Fora Soft.
Configuring EXT-X-PART for low-latency HLS that holds up at scale?
We will tune your EXT-X-PART and segment settings for your latency target and test them through your CDN and players. 250+ video products shipped since 2005.
