Live DASH Manifest indefinite buffering occurs between SSAI ad period and content

[JonWatson]

Version

Media3 1.3.1 and up.

More version details

No response

Devices that reproduce the issue

Pixel 7 running Android 14 * Pixel Tablet running Android 14, others

Devices that do not reproduce the issue

No response

Reproducible in the demo app?

Did not attempt (DRM)

Reproduction steps

• Load one of our DASH DRM-protected Live streams that has SSAI
• Observe acceptable playback during non-Ad periods
• Seek to a position inside an ad-break (or start playback from within an an-break)
• At the end of the Server-side injected ad (when non-Ad period is supposed to start) playback freezes and we see indefinite buffering

The discontinuity does not seem to be handled properly due to something in our DASH Live stream. This problem also occurs on previous versions of Media3 randomly during normal playback, however it is only on Media3 1.3.1 and up that you can easily recreate this issue by seeking into(or starting playback inside) an Ad break. Other players such as Roku do not exhibit this problem with the same streams.

Please note that when this indefinite buffering occurs we can get playback to resume (state goes from buffering -> playing) immediately by creating/attaching a new view to the ExoPlayer instance. This can be easily seen in our app by rotating the screen(maintains ExoPlayer instance, but new view is created/attached). Playback can also be resumed by seeking forward out of the ad period

Also note that this issue usually does not occur if playback starts before the ad-break, then the ad break period plays. Normally, playback just continues seamlessly. It's only if you seek into or start during the Ad period that this easy-to-recreate issue occurs.

I will send a debuggable APK via email with steps on how to login and find some content.

I have HAR files and can reproduce during Live games to gather more info as needed.

Attaching logs of occurrence.

Reds at Blue Jays - ExoPlayer Logs.zip

Expected result

Video always continues playing through the Ad period and back into the non-Ad period without indefinite buffering

Actual result

Indefinite buffering

Media

Currently unable to share

Bug Report

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

[JonWatson]

Hello, @marcbaechinger . I realize there was not enough info on this ticket. I'm going to send in a debuggable APK with EventLogger turned on today and instructions on how to recreate. I am also opening a separate issue regarding frequent DashManifestStaleException errors that Media3 encounters, which also seem related to the SSAI Ad periods in our Live DASH manifests. However, I think/hope that these two issues are related.

[JonWatson]

APK and instructions have been sent. I'm available any time to help, thank you!

[tonihei]

Assigning to me for now, please see comments in https://github.com/androidx/media/issues/1734#issuecomment-2402535243 for further details.

[JonWatson]

We've found that this problem can be resolved by making the Ads periods clear (no DRM) but unfortunately that solution causes issues for some other platforms. Aside from rotating the device, we can also attempt to recover by doing a very short seek forward. I will post a sample stream later today

[JonWatson]

@tonihei I've sent an email to [email protected] with a manifest URL. If you send me a message during the day when you have time, I can likely get you a Live manifest right at that moment as the issue is easy to recreate at any time of day, but our manifests are only live for 30-60m. Except for MLB Games (night time) which are available for about 3hrs.

I'm unsure if this one will still be available when you look. Thank you for your help

[JonWatson]

I can actually see a correlation here with Pixel devices. The error and rebuffering rates from Conviva are much higher on Pixel devices. Again, we think this problem is related to our DRM on Ad Periods

[tonihei]

we think this problem is related to our DRM on Ad Periods

Since this moved more towards a DRM-related issue, could you check if DefaultRenderersFactory.experimentalSetMediaCodecAsyncCryptoFlagEnabled(false) helps to resolve the issue? This was turned out by default in Media 1.3.0 (where you reported the issues started), but has since been turned off again due to https://github.com/androidx/media/issues/1641.

I've sent an email to [email protected] with a manifest URL. If you send me a message during the day when you have time, I can likely get you a Live manifest right at that moment as the issue is easy to recreate at any time of day, but our manifests are only live for 30-60m. Except for MLB Games (night time) which are available for about 3hrs.

Thanks, but as you already highlighted, the stream was offline by the time I looked into it. If the problem requires actual playback of the stream with DRM, I'd likely also need the DRM setup (license server etc) to reproduce myself. You could verify whether this is needed by checking if disabling video entirely avoids the issue (TrackSelectionParameters.Builder.setTrackTypeDisabled(C.TRACK_TYPE_VIDEO, true)).

[JonWatson]

I thought for a few moments like this Async Crypto Flag fixed our problem, but apparently not.

Unfortunately the problem does not occur with the video track disabled.

I would be glad to provide our DRM implementation. I could provide a manifest URL and a valid DRM key but again those would likely be time-limited to an hour during the day or ~3 hours during an MLB game at night

[tonihei]

I would be glad to provide our DRM implementation. I could provide a manifest URL and a valid DRM key but again those would likely be time-limited to an hour during the day or ~3 hours during an MLB game at night

Thanks for the offer, but this makes it quite hard to debug because we can't easily commit to specific debug time slots during our day. Given that it seems to be DRM related and correlated with Pixel devices, could you capture a full Android bugreport just after the issue happened? It could be that something goes wrong in the DRM stack and there is often some logging in the bugreport that could point to an issue.

Not sure if you tried yet or if it's enable already, but keeping the secure codec for the non-secure ads can help to avoid any issues with codec switching (in case that's the underlying problem here): https://developer.android.com/media/media3/exoplayer/drm#drm-sessions