The streaming continues beyond the duration if VMAP has scheduled advertises after duration itself

[chemickypes]

Version

Media3 1.5.1

More version details

Media3 1.5.1

Devices that reproduce the issue

All

Devices that do not reproduce the issue

N/A

Reproducible in the demo app?

Not tested

Reproduction steps

Using a VMAP file with advertise scheduled beyond the content duration you will see that streaming continues to the first ads possible after the duration and than it finishes.

Expected result

The streaming finishes when it reaches the duration.

Actual result

the Streaming continues beyond the duration till the first ads after this time.

Media

Here two images to show that buffered position is greater than window duration and that the buffered position is the same of the adBreaks.

Bug Report

• You will email the zip file produced by adb bugreport to [email protected] after filing this issue.

[marcbaechinger]

Thanks for your report.

I assume you are referring to the client-side IMA ad extension of ExoPlayer.

VMAP file with advertise scheduled beyond the content duration
buffered position is greater than window duration

Let me reassure that I understand correctly what you report (numbers are mine to make it a bit easier):

• There is a VOD content stream with a duration of 10_000_000 microseconds (10 seconds)
• There is VMAP file that declares an ad should be inserted at position 12_000_000 which is after the content ended

The expectation is now that playback stops after 10 seconds and the ad at 12_000_000 is not played.

The observed behavior is that the ad is played as a post-roll right at the end of the content and after the post roll is played, playback stops with STATE_ENDED.

Do I understand your report correctly?

In any case, would it be possible that you can provide us with an ad tag URI, so we can repro this in the demo app? This would expedite the investigation and possible fix.

If you're unable to share bug test content publicly, please send them to [email protected] using a subject in the format "Issue #2215". Please also update this issue to indicate you’ve done this.

[chemickypes]

yes you understood the problem but between the end of the content and the commercial, the streaming is frozen and the user have to wait for the time gap between the end and the ads break.

I am going to write you an email with link so you can test by yourself.

[marcbaechinger]

Sorry for my late response and thanks for providing the assets for testing.

I was able to use the media and VMAP file you sent by email. Besides the pre roll the ads have a load error, but generally I think it confirms what we discussed above.

The VMAP file delivers ad cue points that are after the end of the window. When then the end of the window is reached, the player attemps to play these ads which at this point don't have a URI. The player waits for the ads SDK to deliver the URIs, but because the position at which the SDK would start fetching the ad data is never reached, the SDK never delivers an URI and the player stalls playback waiting for that. That's how I understand what's going on.

I think the best solution for this would be to not ad these ad groups after the end of the window to the AdPlaybackState, but this isn't easily possible with the current approach. The reason is that the cue points are inserted to the AdPlaybackState at the very first moment they are delivered from the SDK and before the content timeline is available, that would deliver the duration of the window. This is required to start with the pre roll as soon as possible.

Since Media3 1.6, AdsMediaSource allows the ad groups to grow. So as an alternative, there would probably a way to defer insertion of all ad groups except the pre roll, then wait for the timeline and start inserting the other ad groups by taking into account the now available duration of the window. That would be a rather larger change.

A further approach that comes to mind, would be to verify the ad playback state when the timeline comes in and then mark ads that are outside the window as skipped. That would probably work as well. While this is a cheap solution, it's a bit hacky though and would involve that event correct VMAP/VAST file would need to spend CPU cycles for this probably on every timeline update.

Obviously, and probablyt not very helpful for you, a solution on your side would be to use a VAMP that doesn't exceed the window duration. I think it's equally obvious though that the ExoPlayer should be able to handle such inaccuracies in the AdPlaybackStates that is a result of a public API that needs validating, so we should provide a fix for this. We have to think about how to fix this in a good way.

I can't give you a concrete timeline for when we get around to this I'm afraid.

[marcbaechinger]

Closing as the change from above does not take ads into the AdPlaybackState that are after the end of the window.