HLS Interstitial support for live sliding window

[TomVarga]

HLS Interstitial support for live sliding window

HLS Interstitial should work for live sliding window content too.

Proposed solution

There are probably many things that need to change to make this happen, probably the most difficult is the timeline handling as the start position shifts with every playlist update.

[tonihei]

I believe this is already supported except for a few special tags (on the main branch, to be released with 1.8.0). @marcbaechinger will be able to confirm.

[marcbaechinger]

In the main branch, there is support for live with HlsInterstitialsAdsLoader.

I'm not sure if this is what you are looking for. From past post my understanding is that you are seeking to support HLS interstitials on your own by reading the manifest/playlist.

So if you want to use the implementation for HlsInterstitialsAdLoader then you'd need to look into the main branch as this isn't released yet.

If your request is only about having interstitials parsed in the playlist this should work already with 1.6 because this is done by core ExoPlayer, not the ads loader.

the timeline handling as the start position shifts with every playlist update.

This only affect the window position and not the period position. The period position is monotonically increasing. Roughly, the window position is then calculated by using the playlist start position that can be subtracted from the period position.

should work for live sliding window content too

Can you elaborate your report a bit around what exactly isn't working?

[TomVarga]

Please bare with me, I need a bit of time to do a setup in the demo app to show/double check that my issue is still their on main. (I am also going on vacation next week, so this might take longer)

[marcbaechinger]

oing on vacation next week

Me too. :)

[TomVarga]

Hi @marcbaechinger

Hope you had a great vacation.

I had a bit of time to look into this and it looks like playback at least works but I am not sure about a few things:

I'd appreciate some guidance on a couple of things:

1. I am not immediately seeing how can I skip an ad?
   Looked like as if getAdsResumptionStates would be where I get the adPlaybackState, but that looks like it is ignored for live.

2. Looks like when the stream is seeked past an interstitial (for example to start at live position) then an interstitial is always played first. I am not immediately seeing how to prevent this besides something like keeping state myself and returning empty asset list for the given interstitial.

[TomVarga]

There seems to be an issue with live streams when more than one interstitial is present.

I have a couple of test streams that allowed me to narrow down the potential issu:

This is an AOD (has END tag) stream that works:
https://raw.githubusercontent.com/TomVarga/HLS-test-stream/refs/heads/main/ride/audio_full_2.m3u8

This is almost the same playlist except it does not have an END tag (hence it's considered a live stream) and only has one interstitial:
https://raw.githubusercontent.com/TomVarga/HLS-test-stream/refs/heads/main/ride/audio_almost_full_single.m3u8

Then there is this stream which is almost exactly the same as the AOD one, but it does not have an END tag (hence it's considered a live stream), it does have two interstitials in it, and this one does not work, playback does not start, chunks are not loaded
https://raw.githubusercontent.com/TomVarga/HLS-test-stream/refs/heads/main/ride/audio_almost_full.m3u8

I am gonna keep looking at the code of what might be wrong, but feels like the issue is somewhere in media3. If you could also help look into this @marcbaechinger that'd be great.

[TomVarga]

Hi @marcbaechinger

Hope you had a great vacation.

I had a bit of time to look into this and it looks like playback at least works but I am not sure about a few things:

I'd appreciate some guidance on a couple of things:

1. I am not immediately seeing how can I skip an ad?
   Looked like as if getAdsResumptionStates would be where I get the adPlaybackState, but that looks like it is ignored for live.
2. Looks like when the stream is seeked past an interstitial (for example to start at live position) then an interstitial is always played first. I am not immediately seeing how to prevent this besides something like keeping state myself and returning empty asset list for the given interstitial.

Any chance you could provide some guidance on this @marcbaechinger ?

[marcbaechinger]

I am not immediately seeing how can I skip an ad?

Currently, you can't without writing you own ads loader. We have plans to add this to HlsInterstitialsAdsLoader soon. I'm trying to get around to move the needle forward with this but I can't give you a timeline for this I'm afraid. The idea is to provide an API to skipCurrentAd() and probably skipAd(adGroupIndex, adIndexInAdGroup). It's not yet decided. If you want to let me know your use case and whether that API would be sufficient for you, you can guide us a bit on what users need. Happy to hear your thoughts.

Looks like when the stream is seeked past an interstitial (for example to start at live position) then an interstitial is always played first. I am not immediately seeing how to prevent this besides something like keeping state myself and returning empty asset list for the given interstitial.

We currently on support X-RESTRICT as having both properties set like "SKIP, JUMP". We are aware that we don't support the entire spec with that, but this is a restriction that is in ExoPlayer core (MediaPeriodQueue) that isn't quick to change. I can't give you any timeline for when these parts of the spec being supported by ExoPlayer. I simply don't know.

However, I see that there are use case where this can be critical, like when joining a live stream and the user shouldn't be forced to immediately watch an ad behind the join position. This may be annoying when the live window is sufficiently long and has ads. Like in a live TV app this may make a user have to watch an ad each time when switching channels. This may be desired by an app, but not wanting this seems valid as well.

While full support for X-RESTRICT probably isn't available soon, we may be able to handle some of these cases with a workaround within the ads loader itself.

Can you give me an idea of what your use case is? Is this for VOD where you want to have a different behaviour or is it the user-joins-live-stream case?

[TomVarga]

My focus is specifically on live sliding window content.

User joining the livestreams is one case.

I mean also being able to just skip any ad at any time I feel is a completely valid business use case where you prioritize user experience over Ad revenue. Not quite sure what API would be best for this.

Also have a bit more involved case:

When you are on the live edge, sometimes the Ad delivery engine (service) can't provide exact match for the interstitial duration, so in this case we use something called a "shim" (it's like elevator music) to fill the remaining dead air (don't want to play the primary content as it might be jarring to hear something completely "off beat"), this "shim" is at least as long as the interstitial on it's own.
The business goal is to only play this till the resumeOffset enters the live window, and at that point skip the remainder of the "shim" and transition back to the primary content at the defined resumeOffset.
So for this case skipCurrentAd() would work I think (as long as resumeOffset is honored)

I think we also need a way to reset interstitials so to speak. What I mean is:
If an interstitial just finished and I seek back before it's startPosition then there should be an API to reset this interstitial so it can be played out again. The business use case is obviously that replaced ads are more revenue than what's already in the stream.

[marcbaechinger]

play this till the resumeOffset enters the live window, and at that point skip the remainder

Sounds like X-PLAYOUT-LIMIT would be useful. We haven't implemented this yet, but I once made a prototype and this worked after we teach AdsMediaSource to clip it's ad sources. Not sure when we get around to work on this though.

You are right that a programmatic SKIP API would be helpful until the X-PLAYOUT-LIMIT is supported (at least in case you own the playlist and can change the interstitials declaration in there).

Generally, for your use cases it seem that being able to set the state of an add programmatically would really be helpful for you. An approach that I can imagine is that HlsInterstitialsAdsLoader can be customized by a boolean flag to insert all ads as skipped. This would mean no add is played unless the app changes it's state to AD_STATE_AVAILABLE. So an app could listen to HlsInterstitialsAdsLoader.Listener to which we add a callback onInterstitialInserted(Intestitial, adGroupIndex, adIndexInAdGroup). When the app sees an ad was inserted, it can act upon the insertion it like turning it to AVAILABLE to make it play with the new API.

However, for all of this we would need to have this programmatic API to let apps change the state of an ad. I'll see that we can prioritize this API.

[TomVarga]

onInterstitialInserted(Intestitial, adGroupIndex, adIndexInAdGroup) sounds great as long as you have mentioned we also get a way to set an adGroupIndex AVAILABLE as I think that's not there now either.