Support updating HLS Interstitials according to the HLS spec

[TomVarga]

Use case description

According to the latest version of the HLS spec at https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis#section-4.4.5.1

If a Playlist contains two EXT-X-DATERANGE tags with the same ID
attribute value, then any AttributeName that appears in both tags
MUST have the same AttributeValue. A Server MAY augment a Date Range
with additional attributes by adding subsequent EXT-X-DATERANGE tags
with the same ID attribute to a Playlist. The client is responsible
for consolidating the tags. The subsequent EXT-X-DATERANGE tags can
appear in a subsequent playlist update, in the case of live or event
streams.

In a live stream scenario our system does updates to an interstitial according to the spec.

Here is simplified example stream:

https://raw.githubusercontent.com/TomVarga/HLS-test-stream/refs/heads/main/ride/audio.m3u8

Proposed solution

I am creating a PR to show my proposed solution, which is going to allow updating the interstitial, but still require the START-DATE for the first appearance of the interstitial.

[marcbaechinger]

Thanks for your request!

To summarize the conversation we had.

Possibly needs a change in HlsMediaPlaylistParser
ExoPlayer already supports updating interstitials in the sense that when a playlist is fetched multiple times in the context of a live stream, the playlist is parsed again and reported for instance with onTimelineChanged(Timeline) where an app can get the manifest from Window.manifest. ExoPlayer in this case doesn't even compare or something instead there are two playlist instances created and reported that may have different interstitials. That's a very simple and clear approach that a value as it's strength.

There is an open question regarding the START_DATE attribute which is covered by #2428. In case the spec is changed to allow to remove the START-DATE attribute in a second occurence of the interstitial with the same ID, we'd have to adjust the parser to allow this. Currently, this fails because of START-DATE being required according to the spec.

It's ubnclear whether this needs to be physically merged in HlsMediaPlaylist or whether just the new playlist can contain the new version fetched from the web. That would be more efficient, but needs to be decided when we implement this.

Update in HlsInterstitialsAdsLoader
Besides the question around the START-DATE attribute, the HLS spec has added that interstitials are allowed to change by adding new attributes. If the same attribute is provided, the value must be the same, but it's ok to a) add new attributes and b) drop attributes already provided with the first occurence of the interstitials of the given ID (if not required, see above). The client, for instance ExoPlayer, would then be responsible to consolidate this by merging the attributes.

HlsIntersitialsAdsLoader would need to be changed to interpret the changes in the interstitials and update the corresponding AdPlaybackState.AdGroup accordingly.

[marcbaechinger]

ADDENDUM: I think I have not considered that part correctly: 'If a Playlist contains two EXT-X-DATERANGE tags with the same ID' My interpretation was wrong as I assumed that the same date range tag appears twice in two sequential playlist, while the wording from above actually says that the tag may appear twice.

I think in practice this would probably be a mixtures as a first playlist may have one tag while then the next has two with the second one having additional attributes.

I still think it's a good idea to wait for whether the discussion in the mailing list is followed by a change or clarification in the spec. I think my concern regarding older clients still applies.

[marcbaechinger]

Closing this given the commits from above.