Keep the same DRM Session for live zapping

[Xlcghs]

Hi,

I ask you following the issue #7286

Use case

User switch between protected content: content A -> content B -> content A

Target

I want to reuse the content's DRM session when the user switch between content A -> content B -> content A for the purpose of optimizing the start-up time of the PlayBack

ExoPlayer Version

2.12 (with the DRMSessionKeepAlive mechanism enabled by default)

Result found:

I put the contents A and B in a playlist to use a single ExoPlayer instance for the playback, I noticed that the DRM License is requested at each switch between contents.
In addition, at the time of the switch, the decoder is disabled which causes a first DRM release (Session keept Alive) and later a release of sampleQue which
causes a total release of the DRM session from which the DRM session kept alive is completely released.

So, Even with the DRMSessionKeepAlive mechanism, is the customization of DRMSessionManager essential to reuse the DRM session ? If so, should you put the DRM session in the cache to reuse it later?

Alternatively, do you think of a similar evolution in the next versions of ExoPlayer?

Best Regards,

[icbaker]

I can reproduce this by using the demo app, playing the Playlists > Clear -> Enc -> Clear -> Enc -> Enc sample and skipping through using the 'next track' button in the UI. The encrypted items are identical (so the keys should be the same and re-usable). I added extra logging to DefaultDrmSession to fire when a session is first acquired and when it's finally released (including logging referenceCountListener.hashcode as a proxy for the instantiating manager) and saw that each session is opened by a different manager (not sure why the 3rd item has a different schemeDatas.hashcode, but not really relevant for now):

2021-02-01 10:40:36.337 23632-23886/com.google.android.exoplayer2.demo W/: Opening session. schemeDatas.hashcode=1076567477, referenceCountListener.hashcode=169872472, this.hashcode=125321649
2021-02-01 10:40:53.090 23632-23886/com.google.android.exoplayer2.demo W/: Opening session. schemeDatas.hashcode=1076567477, referenceCountListener.hashcode=84144163, this.hashcode=65673504
2021-02-01 10:40:59.758 23632-23886/com.google.android.exoplayer2.demo W/: Opening session. schemeDatas.hashcode=1294581436, referenceCountListener.hashcode=40083533, this.hashcode=131131138

The keepalive is 'working' in the sense the sessions aren't released immediately after transitioning out of the associated period (they all get released when pressing the UI back button and returning to the sample chooser page, because this releases the player and all associated resources).

However the keepalive isn't helping you, because DrmSession instances are cached/re-used at the DefaultDrmSessionManager level, and by default each MediaItem in the playlist has a new DefaultDrmSessionManager.

You can change this behaviour by passing a single manager instance to MediaSourceFactory#setDrmSessionManager() when setting up your player: https://exoplayer.dev/media-sources.html#customizing-media-source-creation

This instance will then be used for every item in the playlist.

Note that this method will be deprecated in 2.13 and replaced by a setDrmSessionManagerProvider() method, with the expectation that if you want to re-use the same instance you'll pass a provider that always returns the same instance.

[Xlcghs]

Thank-you for your prompt response
It works fine with this customization.

On the other hand, if I use a single ExoPlayer instance for a live stream which contains multiple channels (without playlist), does this customization remain valid so that I reuse a key?

[icbaker]

On the other hand, if I use a single ExoPlayer instance for a live stream which contains multiple channels (without playlist), does this customization remain valid so that I reuse a key?

Not sure what you mean by 'channel' here. My suggestion will work so long as the DrmSessionManager instance remains unreleased. It will be released when a MediaSource is released. So if your use-case involves releasing media sources before acquiring a new one, then the reference count inside DrmSessionManager might drop to zero, causing it to release its cached sessions.

You can likely avoid this by manually holding a reference - i.e. call prepare() on the manager before passing it to the MediaSourceFactory then call release() when you know for sure you're done with it. This will prevent the internal reference count ever reaching zero, and ensure the cache of sessions is never purged.