WWDC Quick Look 💓 By SwiftGGTeam
Adapt ad insertion to Low-Latency HLS

Adapt ad insertion to Low-Latency HLS

Watch original video

Highlight

The server-side ad insertion of Low-Latency HLS requires advertising to be published according to Partial Segment, and providing Blocking Playlist Reload and preload hints for both advertising and program content to maintain a low-latency playback model when advertising is switched.

Core Content

Ad insertion in ordinary live broadcast HLS works based on segment boundaries. The program source has a marker for inserting advertisements. The packager adds a short program segment before the advertisement starts, aligns the boundary to the segment, and then uses the discontinuity tag to cut to the advertisement. After the commercial ends, it fills in a short commercial segment and then switches back to the program.

Low-latency live streaming thins out this model. The client no longer waits for the complete segment to appear, but reads the shorter Partial Segment against the live edge. A 6-second parent segment can be split into multiple 2-second partials. The client can get the first piece of media in two seconds without waiting for the full 6 seconds.

Ad insertion therefore cannot publish only the full ad segment. After the advertisement starts, the packager also publishes advertisements Partial Segment every partial duration. The parent segment still exists, and the discontinuity, boundary alignment, and key rotation positions remain unchanged. The change is in live edge: players see partial ads that appear more frequently.

There is another common trouble in live broadcast: early return. During the live broadcast of the event, the producer may cut back to the scene before the commercial is finished. At this time, the server needs to stop advertising partial, add a short parent segment up to the current point, update the preload hint, and let the client move to the next program partial.

Detailed Content

Partial Segment changes the rhythm of ad insertion

(01:51) Low-Latency HLS uses Partial Segment at the live edge. The speech uses 6 seconds segment and 2 seconds partial. For example: the client can get the first part of the segment after two seconds, more content after four seconds, and the last partial and parent segment after six seconds.

This rhythm directly affects advertising. The packager cannot wait for the complete advertising segment to be ready before updating the playlist. It needs to continuously publish partial advertisements during the parent segment generation process, so that the client can play the advertisement segment according to the same set of live edge rules.

Key points:

  • parent segmentIs a complete regular HLS segment.
  • Partial SegmentHosts the same piece of media, but appears earlier in the playlist.
  • The client uses Partial Segment to play close to the live edge to avoid waiting for the release delay of the complete segment.
  • The advertising content must also be published according to the partial duration first, and the parent segment will appear later. Otherwise, when switching to the advertisement, it will fall back to the normal HLS delay model.

Ad boundaries are still aligned by short segment and discontinuity

(02:54) Server-side ad insertion for normal HLS handles boundaries first. The marker does not necessarily fall on the regular segment boundary. The packager may generate a short program segment so that the advertising start point falls exactly on the segment boundary. When switching ads, use discontinuity tags to separate programs and ads.

The typical sequence is: the program source gives a marker that can be inserted into advertisements, the decisioning engine selects the advertisement, the packager uses the short program segment to align the advertisement starting point, and then replaces the subsequent program segment with the ad segment. The advertising end point may not be on the regular segment boundary, so the packager also generates a short advertising segment and then returns to the program content.

Key points:

  • marker comes from the program source and indicates where advertisements can be inserted.
  • The short program segment makes the starting point of the advertisement a clear boundary.
  • discontinuity tag marks the switch between program content and advertising content.
  • The ad end point may also not be on a segment boundary, so a short ad segment is required.

Ads must also be published as Partial Segment first

(04:20) Low-latency scenarios continue to use the same set of ad boundaries, but in a finer publishing order. After the advertisement starts, the packager first publishes the partial advertisement according to the partial duration; when all partials of a parent segment are available, the complete advertisement parent segment is released.

The timeline in the speech is: the program partial progresses normally, and a short program partial and parent segment appear before the advertising boundary. After entering the advertisement, the packager adds an advertisement partial every two seconds partial duration. After a complete advertising segment is assembled, the parent segment appears. When the ad ends, use the short ad partial to align the boundaries, then resume the partial and parent segments.

Key points:

  • The positions of ad boundary, discontinuity and key rotation remain on the same timeline.
  • The difference in low latency occurs at the publishing granularity: the advertising segment is first split into Partial Segment and appears on the live edge.
  • The packager must maintain the same low-latency timing model for both programs and ads.
  • If ads are only published in complete segments, the player will lose the low-latency advantage in ad segments.

Blocking Playlist Reload also covers advertising paragraphs

(05:48) The speech explicitly requires origin to also implement Blocking Playlist Reload for ads. When a client requests the next playlist version, the server does not return the old playlist immediately, but waits until a new partial or segment is available.

This requirement does not only apply to program content. Before the advertisement partial enters the playlist, the origin must also maintain the same waiting semantics. In this way, the playlist obtained by the client will continue to be close to the live edge, instead of repeatedly receiving outdated versions in the advertising paragraphs.

Key points:

  • Blocking Playlist Reload is part of the HLS Origin API.
  • It protects the playlist update timing, not only applicable to program content.
  • If the advertisement segment returns to the old playlist immediately, the client will get the stale playlist, and low-latency playback will be slowed down.
  • Advertisements and programs share the same waiting and publishing rhythm, so the player does not need to change strategies at switching points.

Preload hints To prompt ad MAP and ad partial

(06:08) Preload hinting requires the playlist to write out the next expected resource URL. When the advertisement is switched, the playlist can first prompt the new media initialization section, and then prompt the first Partial Segment of the advertisement.

In the speech example, segment 7 was the last available program content at that time. Two preload hints are given at the end of the playlist: one to prompt the client to load the new media initialization section required for the ad, and one to prompt the first partial of the ad. Two seconds later, the playlist updates the discontinuity, ad map tag and first part tag of the ad, and the new preload hint points to the second part of the ad.

Key points:

  • TYPE=MAPPrompts new initialization information that will be used for ad content.
  • TYPE=PARTCue next ad Partial Segment.
  • Commercials are pre-recorded content, ad origin does not need to wait for encoding to complete like live program sources.
  • The playlist still needs to continuously update the hint so that the client always knows the next advertising resource to be requested.

Update hint when early return, switch back to the program directly

(07:55) early return means that the live broadcast producer ends the commercial early and immediately switches back to the program. The server can stop publishing subsequent advertising partials, fill in a short parent segment up to the current published partial, and then use discontinuity to switch back to the program.

The key processing point is hint. The server may have previously prompted the next advertisement partial. After it knows that it wants to return to the program early, it needs to change the hint to the next program partial. After the client sees the new hint, it will switch back to the loading path of the program content.

Key points:

  • Old hints that have been emitted may point to the next ad partial.
  • After the server knows that it wants to return the program early, it changes hint to the next program partial.
  • When the client sees the new hint, it stops loading along the ad inventory.
  • This processing allows sudden live content to be returned to the program immediately while preserving a low-latency loading path.

Core Takeaways

  • What to do: Add an advertising partial publishing link to the low-latency live broadcast packager. Why it’s worth doing: The speech clearly pointed out that ads in LL-HLS must first appear in the live edge as Partial Segment. How ​​to start: Reuse the partial duration of the program content, cut the creative into partials with the same rhythm, and publish the full parent segment when it is available.

  • What to do: Make ad switching points into observable playlist check items. Why it’s worth doing: Ads start and end with short segments, discontinuity, and border alignment. How ​​to start: Scan the playlist near the ad marker in the automated check and confirm that the short segment, discontinuity tag, ad map tag and ad partial are in the correct order.

  • What: Implement hint rewrite capability for SSAI (Server-Side Ad Insertion). Why it’s worth doing: Early return will invalidate the published advertising hint, and the server must redirect it to the program partial. How ​​to start: When the decision engine sends an early return signal, let the packager generate a short ad parent segment and change the next preload hint to a program URI.

  • What to do: Configure the blocking semantics of ad origin and program origin separately. Why it’s worth doing: The speech pointed out that advertisements are pre-recorded content, and ad origin does not need to force blocking and waiting; playlist origin still needs to perform Blocking Playlist Reload for advertisements and programs. How ​​to get started: Use the playlist generation service as a low-latency control point and let it be responsible for blocking reload and hint; ad media files can be served by ordinary static origin or CDN.

  • What to do: Add live-edge latency curves for ad segments in player tests. Why it’s worth doing: If the ad is returned to full segment release, users will see a delayed jump at the ad. How ​​to start: Record the program partial, ad partial, parent segment and playlist return time, and calculate the live-edge distance before the ad, during the ad and after the ad respectively.

Comments

GitHub Issues · utterances