Cache opened widevine DRM Sessions until `Player.release()`

[stevemayhew]

Use case description

The use case involves streaming a large linear channel list (>100 channels) consisting of Live HLS and DASH playlists, protected by Widevine. Playback is continuous, and "channel zapping" or "channel surfing" is a frequent activity. Channels may be licensed individually or in packages.

Most Android streaming hardware supports a significant number of open MediaDrm session slots (e.g., Google TV Chromecast, based on AmLogic SoC, supports 100 active license slots).

Currently, ExoPlayer retains open sessions for MediaItems in a timed cache, however this cache is flushed whenever any MediaSource that references it is released.

The Playlist avoids this as the MediaItem's in it are associated with MediaSources are not fully released until the MediaSourceList (playlist) is released.

In contrast, changing channels by calling Player.setMediaItems() with a single channel's MediaItem releases the current MediaSource, effectively flushing the DRM session cache every time.

The use case precludes the use of a Playlist due to the following challenges:

1. The Playlist API does not directly preclude multiple live items, however it makes little sense contextually
2. Retaining a fully prepared live MediaSource consumes significant CPU, memory, and network bandwidth, as it retains source buffers and continues polling live playlist refreshes.
3. Linear channel provisioning often occurs on-the-fly, making it impractical to pre-create a playlist of 100+ channels before playback starts.

Related Requests

The issue #394 presented a very similar request, however it looked like the request was to persist licnese after process exit.

The Widevine CDM platform will not support this as the open MediaDrm sessions owned by a process are released on process exit. In fact it is not really valid to retain open MediaDrm sessions while the Activity is not in the foreground as they are a shared hardware resource.

Proposed solution

Pull request #2049

Alternatives considered

The Playlist could be made acceptable, but some mechanism for quiescing the Timeline.Window live windows that are not currently playing. The quiesce would stop the playlist tracker and free cached media without fulling releasing the MediaSource. This would be a much more significant change than what is proposed in the pull request.

[icbaker]

however this cache is flushed whenever any MediaSource that references it is released.

I'm not sure I completely agree with this statement.

I think a more precise statement would be:

The cache is flushed when the DefaultDrmSessionManager reference count (as incremented and decremented by DrmSessionManager.prepare() and DrmSessionManager.release() calls) reaches zero.

So if you only have a single MediaSource instance, and it's the only thing holding a reference to your DefaultDrmSessionManager, then I agree that when the MediaSource is released then the DefaultDrmSessionManager will be "fully" released too.

But it should work to do something like this:

1. Use MediaSource.Factory.setDrmSessionManagerProvider to wrap DefaultDrmSessionManagerProvider and hook the DefaultDrmSessionManager that is returned, and if it's one you haven't seen before then cache it and store your own reference to it using DrmSessionManager.acquire (and maybe release any previously cached instance).
2. When you release your ExoPlayer also release any cached DefaultDrmSessionManager instance

This should ensure that the DefaultDrmSessionManager instance is kept when you call Player.setMediaItem, and so you should benefit from sessionKeepAliveMs. The default value for this is 5mins, but you could set it much higher (e.g. 12hrs).

[stevemayhew]

however this cache is flushed whenever any MediaSource that references it is released.

I'm not sure I completely agree with this statement.

I think a more precise statement would be:

The cache is flushed when the DefaultDrmSessionManager reference count (as incremented and decremented by DrmSessionManager.prepare() and DrmSessionManager.release() calls) reaches zero.

So if you only have a single MediaSource instance, and it's the only thing holding a reference to your DefaultDrmSessionManager, then I agree that when the MediaSource is released then the DefaultDrmSessionManager will be "fully" released too.

Thanks @icbaker!

Correct this is our situation, single MediaSource at a time, same as the issue reported in #394.

The "reference count" you are referring to is prepareCallsCount correct?

So, rather than simply hanging on to the DrmSession that backs the actual open MediaDrm session you are proposing hanging on to the entire DefaultDrmSessionManager. Presumably we would need a map of these keyed by some identifying criteria in the MediaItem's.

This could work, but just not work like the Playlist case, which only has a single DefaultDrmSessionManager instance and would have a few undesirable consequences:

1. It would holding on to multiple copies of the Handler that is managing keep-alive and it's list of DrmSession
2. If there was a ResourceBusyException the handler would not have access to all the cached sessions to release them
3. If two channels shared the same DRM content id (possible if channels are sold as a package), they would not get the benefit of using the same cached DrmSession

We always prefer any supported solution that solves our problem (and issue #394).

Maintaining work-arounds or depending on fluid interfaces in ExoPlayer is setting us up for difficulty in the future.

Thanks again for considering this request. We are happy to look at any suggestions to the pull request #2049, you have write access to it.

[icbaker]

The "reference count" you are referring to is prepareCallsCount correct?

This is the implementation inside DefaultDrmSessionManager, yes.

So, rather than simply hanging on to the DrmSession that backs the actual open MediaDrm session you are proposing hanging on to the entire DefaultDrmSessionManager. Presumably we would need a map of these keyed by some identifying criteria in the MediaItem's.

DefaultDrmSessionManagerProvider already has logic which aims to re-use DefaultDrmSessionManager instances if possible (i.e. if the MediaItem.localConfiguration.drmConfiguration matches). I think the problem you're seeing with this re-use logic is that although the same instance should be used every time you call setMediaItem, that instance's refcount reaches 0 during the switch, so it releases all its sessions. You should be able to confirm this with a bit of debugging/logging, because if you're seeing different DefaultDrmSessionManager instances being used before and after setMediaItem then something else will need to be tweaked (not sure what).

Assuming you do see this single re-used DefaultDrmSessionManager instance, then my suggestion is to just manually increment its ref count yourself, so that during the setMediaItem transition it only reaches refcount = 1, and doesn't release any of its cached sessions. Then you need to manually decrement this when you release the player.

Because I expect the same DefaultDrmSessionManager instance to be re-used, you shouldn't need to maintain any keying between DefaultDrmSessionManager instances and MediaItem - and I think it should resolve your other concerns too?

[stevemayhew]

The "reference count" you are referring to is prepareCallsCount correct?

This is the implementation inside DefaultDrmSessionManager, yes.

So, rather than simply hanging on to the DrmSession that backs the actual open MediaDrm session you are proposing hanging on to the entire DefaultDrmSessionManager. Presumably we would need a map of these keyed by some identifying criteria in the MediaItem's.
...
Assuming you do see this single re-used DefaultDrmSessionManager instance, then my suggestion is to just manually increment its ref count yourself, so that during the setMediaItem transition it only reaches refcount = 1, and doesn't release any of its cached sessions. Then you need to manually decrement this when you release the player.

Because I expect the same DefaultDrmSessionManager instance to be re-used, you shouldn't need to maintain any keying between DefaultDrmSessionManager instances and MediaItem - and I think it should resolve your other concerns too?

Ah, ok.. I see where you are going now, so we would have logic something like this in DefaultDrmSessionManagerProvider

  /**
   * Set the flag to indicate {@link DefaultDrmSessionManager} to cache the DrmSessions
   *
   * @param enable - true means caching ie enabled, false is the default behaviour
   */
  public void setFreeKeepAliveSessionsOnRelease(boolean enable) {
    this.freeKeepAliveSessionsOnRelease = enable;
  }

...

    synchronized (lock) {
      if (!Util.areEqual(drmConfiguration, this.drmConfiguration)) {
        this.drmConfiguration = drmConfiguration;
        if (manager != null && !freeKeepAliveSessionsOnRelease) {
          manager.release();
        }
        this.manager = createManager(drmConfiguration);
        if (!freeKeepAliveSessionsOnRelease) {
          manager.prepare();
        }
      }
      return checkNotNull(this.manager);
    }
  }

We would still need "final" release logic in DefaultDrmSessionManagerProvider that would need to be called when the player itself is released, like this:

  /** Releases all the cached sessions in {@link DrmSessionManager} */
  public void releaseAllDrmSessions() {
    if (this.manager != null && !freeKeepAliveSessionsOnRelease)) {
      manager.release();
    }
  }

Since the player does not directly reference the DrmSessionManagerProvider, the user would need to manually call this.

Would be nice to have this code (or something like it) in the DefaultDrmSessionManagerProvider, as otherwise would need to copy parts of it or delegate (as it is final).

Thanks for your help and advice on this!

[icbaker]

Would be nice to have this code (or something like it) in the DefaultDrmSessionManagerProvider, as otherwise would need to copy parts of it or delegate (as it is final).

Yeah, I would recommend delegating - something like this (untested) if you only care about keeping a single DrmSessionManager instance alive at a time (I suspect this will be enough?):

class CachingDrmSessionManagerProvider implements DrmSessionManagerProvider {

  private final DrmSessionManagerProvider delegate;
  @Nullable private DrmSessionManager cachedManager;

  private CachingDrmSessionManagerProvider(DrmSessionManagerProvider delegate) {
    this.delegate = delegate;
  }

  @Override
  public DrmSessionManager get(MediaItem mediaItem) {
    DrmSessionManager drmSessionManager = delegate.get(mediaItem);
    if (drmSessionManager != cachedManager) {
      if (cachedManager != null) {
        cachedManager.release();
      }
      drmSessionManager.prepare();
      cachedManager = drmSessionManager;
    }
    return drmSessionManager;
  }

  public final void releaseCachedManager() {
    if (cachedManager != null) {
      cachedManager.release();
    }
  }
}

Or slightly more complicated if you want to keep all instances alive:

class CachingDrmSessionManagerProvider implements DrmSessionManagerProvider {

  private final DrmSessionManagerProvider delegate;
  private final Set<DrmSessionManager> cachedManagers;

  private CachingDrmSessionManagerProvider(DrmSessionManagerProvider delegate) {
    this.delegate = delegate;
    cachedManagers = Sets.newIdentityHashSet();
  }

  @Override
  public DrmSessionManager get(MediaItem mediaItem) {
    DrmSessionManager drmSessionManager = delegate.get(mediaItem);
    if (cachedManagers.add(drmSessionManager)) {
      drmSessionManager.prepare();
    }
    return drmSessionManager;
  }

  public final void releaseCachedManagers() {
    for (DrmSessionManager cachedManager : cachedManagers) {
      cachedManager.release();
    }
    cachedManagers.clear();
  }
}

[stevemayhew]

Thanks @icbaker, I see no use-case for multiple DrmSessionManager instances.

BTW, we found a bug where when the drmConfiguration changes and the old DrmSessionManager is overwritten it will leak open DrmSession's. This occurs periodically for us as the licenseRequestHeaders are changed periodically to prevent impersonation attacks.

I'll include that commit separately in an updated pull request so you can pick just that out.

We currently have our own implementation of this that is working in production (survived the US Super Bowl ;-) ), we are willing to work on a pull request together with you for a functionally equivalent implementation if you are motivated to close this issue by work on merging the changes to AndroidX. If not, simply close this RFE.

Again thanks so much for your time here.