WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Discover HLS Blocking Preload Hints

Discover HLS Blocking Preload Hints

HLSLow-Latency HLSStreaming
Watch original video

Highlight

Low-Latency HLS requires playlist release#EXT-X-PRELOAD-HINT, allowing the client to request the next Partial Segment in advance and the server to return it as soon as the segment is available, thus reducing the additional round-trip delay after the media is discovered.

Core Content

The low-latency bottleneck of live broadcast is often hidden in a small gap: after the playlist is updated, the client only knows the URI of the new shard, and then initiates a media request. In a cross-region CDN scenario, a round trip from the edge node to the origin may take more than 100 milliseconds. For live broadcasts where the target delay is only a few seconds, this gap will accumulate repeatedly.

Blocking Playlist Reload has resolved playlist discovery issues. The client can request the next playlist version in advance, and the server will wait for the playlist to be updated before returning. Blocking Preload Hints applies the same idea to media sharding itself: the playlist first writes the hint for the next Partial Segment, the client immediately requests this URL, and the server returns the data after the segment encoding and packaging are completed.

The result is that the media no longer waits until it “sees a new shard” before starting a request. The client usually hangs a Blocking Playlist Reload request and a preload hint request at the same time. When a new Partial Segment completes, the server updates the playlist and releases media requests. By the time the player gets the playlist update, the media data is already on the way.

This session also explains the two delivery models. In the simple model, each Partial Segment has an independent URL. In the CMAF Chunk model, multiple Partial Segments are the byte-range of the same parent segment. The client can use chunked transfer to continuously receive multiple chunks from one request. This makes it easier to serve both Low-Latency HLS and Low-Latency DASH from the same set of media.

Detailed Content

Request the next Partial Segment in advance

(00:48) The goal of Preload hinting is to establish the request before the media is actually available. Playlist must be brought#EXT-X-PRELOAD-HINT,ThatURIPoints to the next Partial Segment that the packager expects to generate.

Last published Partial Segment: part1.1.m4s
Preload Hint points to the next Partial Segment the packager expects to generate: part1.2

Key points:

  • transcript explicitly states that the last published part ispart1.1.m4s。
  • transcript explicitly states that hint tells the client that the next part that can be tried to be loaded ispart1.2。
  • TYPE=PARTIs the preload hint used for the semantics of media Partial Segment.
  • The client immediately requests the hinted URL after seeing the hint; if the shard has not been generated yet, the server keeps requesting and returns after the shard is available.

(02:30) The actual request flow is pretty straightforward. The client first initiates Blocking Playlist Reload, and then initiates a hinted Partial Segment request. After the encoder completes the new Partial Segment, the server simultaneously releases the media response and updates the playlist. The player saves a round of waiting for “requesting media after receiving the playlist”.

Prompt MAP to handle content switching in advance

(02:15) Preload hints can also prompt the upcomingMAP. This is important for content switching such as advertising boundaries, because the player can obtain new initialization information in advance and reduce pauses at switching points.

Before content switching: the playlist can hint at the upcoming MAP.
After content switching: the playlist continues to hint at the next Partial Segment.

Key points:

  • transcript description preload hints can be used for upcoming MAP tags.
  • The purpose of MAP hint is to allow the client to prepare in advance the initialization information required for content switching.
  • At the content boundary, the client will still continue to load subsequent Partial Segments.
  • If the creative is pre-recorded content, the server can return the hint request immediately without blocking and waiting like with live-encoded content.

Use byte-range to express Partial Segment

(03:39) Partial Segment does not necessarily have independent files. It can also be a byte-range in larger resources. Preload Hint tag can be broughtBYTERANGE-STARTandBYTERANGE-LENGTH. When the length has not yet been determined, you can just write the starting position.

Preload Hint can indicate a range in segment 23 that starts at 0 and is 4,044 bytes long.
If the length is not yet known, the hint keeps only the byte-range start position.

Key points:

  • transcript clearly illustrates that hint can point to segment 230arrive4,044scope.
  • The byte-range starting position tells the client where the next Partial Segment starts from the parent segment.
  • The byte-range length tells the client the currently known range size.
  • The length can be omitted if the length is not known when the packager issues the hint.

Continuous delivery using CMAF Chunk and chunked transfer

(04:17) CMAF Chunk can be mapped to a Partial Segment of Low-Latency HLS. The server gradually appends multiple chunks to the same parent segment. The client initiates an open request to the parent segment and continuously receives subsequent Partial Segments through Chunk Transfer Encoding.

First update: the first Partial Segment of segment 1 is the first 3,000 bytes, and the hint updates to start at 3,000.
Second update: a second byte-range appears in segment 1, and the hint updates to start at 8,000.

Key points:

  • transcript clearly states that the first Partial Segment is the front of segment 13,000byte.
  • After the next playlist update, the starting position of hint is updated to3,000。
  • After the next update, the second part appears, and the hint points to the starting position of the next part.8,000。
  • Session reminds you that many CDNs do not support Chunk Transfer Encoding for live content; CDN capabilities must be verified before adopting this model.

Allow the server to change plans

(07:42) Preload Hint is a plan, not a promise. After the server releases the hint, the next content can still be changed. A common scenario is that the operator decides to return to live broadcast from advertising in advance.

The server has already published a hint.
The operator decides to return from the ad to the live stream early.
The next playlist update does not contain the previously hinted URL.
The client cancels the pending hint request and switches to the content that actually appears in the playlist.

Key points:

  • transcript Explain that the server can still change the plan after issuing a Preload Hint.
  • A common reason is that the operator decides to return to live streaming from advertising early.
  • The next time the playlist is updated, if the previously hinted URL does not appear in the playlist, the client will cancel the pending request.
  • The client then loads the new Partial Segment that actually appears in the playlist.

Core Takeaways

  • Request timing dashboard for low-latency live broadcast: Draw Blocking Playlist Reload, preload hint request, and Partial Segment return time on the same timeline. Why it’s worth doing: Session emphasizes that these two blocking requests will usually hang at the same time and return close to the same time. How to start: Log the playlist request, hint request, HTTP unblock time and part URI in the player and edge service logs, then press#EXT-X-PRELOAD-HINTAlignment.

  • Do hint consistency check for HLS packager: Verify whether each hinted URL will be used as a hint in subsequent playlists#EXT-X-PARTor#EXT-X-MAPAppear. Why it’s worth doing: The server can change plans, but common errors can cause clients to request invalid resources. How to start: parse consecutive playlist snapshots, trace#EXT-X-PRELOAD-HINT, confirm that the URI and byte-range match in the next update.

  • CDN capability detection tool: Check whether the target CDN supports Chunk Transfer Encoding for live broadcast scenarios. Why it’s worth doing: The CMAF Chunk solution can reuse the same set of media services Low-Latency HLS and Low-Latency DASH, but Session clearly reminds that many CDNs do not support this live delivery method. How to start: Initiate a long connection request to the test parent segment, the server gradually appends chunks, and the client records whether the data can be received in batches.

  • Advertising Boundary Preload Verification: Specialized TestingTYPE=MAPandTYPE=PARTBehavior during ad insertion and early cutback to live broadcast. Why it’s worth doing: Session mentions that MAP hints can help with content switching, and also indicate that the server may change plans mid-advertisement. How to start: Prepare a test stream containing three types of playlist updates: live streaming, advertising, and early return, and check whether the player cancels the old hint and loads the new shard.

Comments

GitHub Issues · utterances