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.
