Analytics onLoad events for HttpMediaDrmCallback requests

[stevemayhew]

Analytics onLoad events for HttpMediaDrmCallback requests

[stevemayhew]

@icbaker I'm curious why DefaultDrmSession.RequestHandler was even implemented rather than using the existing com.google.android.exoplayer2.upstream.Loader. which does largely the same thing with a richer set of API calls to observe and manage the load.

[icbaker]

Alternatives considered

Adding logging to the HttpMediaDrmCallback, this is simple but not as useful as a hook that allowed using AnalyticsListener to post the data to operational logging.

Not sure if this is what you meant, but to be explicit: you can add a TransferListener to the DataSource.Factory you pass to HttpMediaDrmCallback, and you should get some callbacks including URLs etc.

---

@icbaker I'm curious why DefaultDrmSession.RequestHandler was even implemented rather than using the existing com.google.android.exoplayer2.upstream.Loader.

Good question - I'm afraid I don't know the reasoning at the time, but I suspect it might have been felt that the Loader machinery was a bit heavyweight for "just" making an HTTP request that you expect to complete fairly quickly (vs e.g. keeping a long-running HTTP request open while you load a whole MP4 movie).

---

We could:

1. Add load statistics to the existing drmKeysLoaded event
2. Add two new events (drmKeyRequestStarted, drmKeyRequestCompleted)

I like (1) more than (2), because we could also include additional info like the type of key load (offline, renewal, etc).

Is this something you'd like to send a PR for? I suggest keeping the existing DrmSessionEventListener.onDrmKeysLoaded(int windowIndex, MediaSource.MediaPeriodId) method and deprecating it, then adding a new onDrmKeysLoaded(int, MediaPeriodId, KeyLoadInfo) method (type name TBD). You will want to ensure that both are invoked from DrmSessionEventListener.EventDispatcher.drmKeysLoaded. Similar on AnalyticsListener (though without the duplication there - each method should just forward directly I think, to avoid too much duplication).

You can probably hard-update the DrmSessionEventListener.EventDispatcher.drmKeysLoaded method to take the new KeyLoadInfo type without deprecating the zero-arg overload, since direct usages of that are probably quite rare (custom DrmSessionManager impls only really) - and maintaining both becomes tricky (since you have to synthesise a 'fake' KeyLoadInfo which is a bit confusing).