#EXT-X-PRELOAD-HINT Explained: Prefetching Partial Segments Before the Playlist Updates

Low-Latency HLS introduced a small tag with an outsized effect on live stream startup and segment delivery: #EXT-X-PRELOAD-HINT. Understanding it requires understanding what problem it solves — which starts with the normal polling loop that a standard HLS client runs.

How a standard HLS client finds new segments

In a non-Low-Latency live stream, a player finds new content by repeatedly polling the media playlist. It fetches the playlist, reads the list of segments, downloads any that are new, and then waits a moment before polling again. The wait is typically half the #EXT-X-TARGETDURATION — so a six-second target duration means roughly three seconds between polls. This adds latency: a segment produced at second zero might not reach the player until second three or four.

Low-Latency HLS addressed the polling problem in two steps. First, it introduced partial segments — small chunks of a segment, often 200ms, so the player does not have to wait for a full six-second segment before getting new content. Second, it introduced blocking playlist reload: instead of polling on a fixed interval, the client appends _HLS_msn and _HLS_part parameters to its playlist request, and the server holds the HTTP response open until the requested partial segment is ready. This brings end-to-end latency down from several seconds to roughly the target part duration.

The remaining gap: segment fetch starts after playlist update

Even with blocking playlist reload, there is a small latency floor. The sequence looks like this:

1. Client sends a blocking playlist request for part N of segment M.
2. Server holds the response while it produces part N.
3. Part N is ready. Server includes it in the playlist and sends the response.
4. Client receives the updated playlist and reads the URI for part N.
5. Client starts fetching part N from the segment server.

Steps 4 and 5 take time. The client has to process the playlist response, find the new URI, and then initiate a second HTTP request to fetch the actual bytes. That gap — even if it is only a few hundred milliseconds — is avoidable.

What #EXT-X-PRELOAD-HINT does

#EXT-X-PRELOAD-HINTis a tag the server adds to the current playlist that says: "the nextpartial segment will be at this URI — start fetching it now."

A conforming LL-HLS client that sees this tag immediately issues a fetch request to the advertised URI, even though that segment has not been produced yet. The fetch blocks at the HTTP layer, waiting for the server to begin responding. The moment the partial segment is ready, the server begins streaming the response bytes — and the client is already waiting for them.

The tag has two required attributes:

• TYPE=PART (or TYPE=MAP for initialization segments)
• URI="..." — the URI of the upcoming partial segment or map

In the playlist, a preload hint appears after the last finalised partial segment line. The client fetches the hinted URI immediately. Once that part is finalised, the server adds it to the playlist as a normal #EXT-X-PART entry and removes the hint, replacing it with a new hint for the part after that.

Interaction with blocking playlist reload

Preload hints and blocking playlist reload work together. While the client is already fetching the hinted segment, it simultaneously sends the next blocking playlist request for the part after the hint. This means:

• The segment fetch is in flight as soon as the hint appears.
• The next playlist update arrives just as the current segment finishes downloading.
• The client is always either receiving data or pre-positioned to receive the next batch — there is no idle period between segment availability and fetch start.

This is why LL-HLS with preload hints can achieve latency in the 1–2 second range on a well-configured origin — something completely out of reach with standard HLS polling at 3–6 second intervals.

How this site's player uses preload hints

The /play route uses hls.js with lowLatencyMode: true when the stream is detected as a live broadcast (via the ?broadcast=1 flag). hls.js implements the full LL-HLS client spec, including reading #EXT-X-PRELOAD-HINT tags and issuing the prefetch request automatically.

Not every live stream uses LL-HLS. The server must explicitly advertise it via #EXT-X-SERVER-CONTROL with CAN-BLOCK-RELOAD=YES and PART-HOLD-BACK. If the stream does not expose these tags, the player falls back to standard polling — preload hints are simply absent, and there is nothing to prefetch.

Preload hints and the /convert route

The /convert converter does not use preload hints at all. Conversion is a download operation over a VOD-style sequential fetch — the converter reads the playlist once, enumerates all segments in order, and downloads them. There is no real-time playback loop, no blocking reload, and no reason to prefetch segments before they appear in the playlist.

Even when pointed at a live stream, the converter captures the segment list at the moment it reads the playlist and converts what was available then. It does not keep pace with new segments being appended in real time. That distinction — live vs. VOD recording — is covered in more detail in the linked post.

Want to see low-latency live playback in action? Install the extension and open a live HLS stream on any page to play it through the low-latency player.