DRM - Fetch keys ahead of the playback position

[ojw28]

Spun out from #3780. The issue is as described in the title.

[ojw28]

Useful background: https://exoplayer.dev/drm.html

This issue can occur where key rotation is present in the media, where the media consists of different quality streams with different keys, and when playing playlists containing DRM protected content.

The problem is that DRM keys are only requested at the point of playback. The solution will be to request them earlier (e.g. one option is to request them at the point of buffering).

[juechemparathy]

@AquilesCanta - This seems affecting our playback experience too. Please let me know if you need any help with test streams. Thanks.

[AchibanaUkyo]

@AquilesCanta Do you consider the key rotation stream which the pssh is only in segment? some encoder/packager won't put the pssh in mpd for live key rotation stream so you can't fetch license in the MediaSource. To be able to retrieve license earlier maybe trigger the license request after demuxing before rendering?

[AquilesCanta]

We are working on other DRM improvements at the moment, please be patient. A commit will appear below once we push something to the dev-branch.

[AquilesCanta]

To be able to retrieve license earlier maybe trigger the license request after demuxing before rendering

@AchibanaUkyo That's what we intend to do.

[rafakob]

Hello!
Is there somewhere a work-in-progress branch? I'm implementing server side DAI for live DASH streams (multi period). When player is switching from advert period (non DRM) to content period (DRM Widevine) I can see a short buffering (around 1 sec).

Time is of the essence here and I'm wondering how I could fix that by myself. Could you give me possible solutions or point me into right direction?

[seanvi24]

We are working on other DRM improvements at the moment, please be patient. A commit will appear below once we push something to the dev-branch.

Hello, Do you have a date estimate of when the update will be committed? Thank you.

[icbaker]

We haven't implemented key pre-fetching, but 316f8a8 implements session keepalive inside the DefaultDrmSessionManager. By default sessions are kept for 5 minutes after the last 'release' - this can be customised with DefaultDrmSessionManager.Builder#setSessionKeepaliveMs(long).

This is enough to bridge a clear ad-break, so if the content before and after the ad is encrypted with the same keys then the session should now be re-used after the ad (e.g #4133 (comment)). This doesn't help for content with key rotation - so I'll keep the issue open to track implementing proper key-prefetching.

This is available on the dev-v2 branch - please try it out and let us know if you spot any problems!

[icbaker]

This is now implemented on the dev-v2 branch - it will be included in the next major release.

I'd appreciate it if people could try it out and report any issues they observe.