Repository navigation
Analytics onLoad events for HttpMediaDrmCallback requests #1001
Description
Use case description
An often significant delay for first frame with channel tunes occurs because of delays from the DRM License Server key or provisioning requests, it would be nice to have analytics events for these.
Proposed solution
The standard MediaSourceEventListener report details for DATA_TYPE_DRM for fetches from EXT-X-KEY with an actual key URL, However the same level of details is missing from the DrmSessionEventListener events.
We could:
- Add load statistics to the existing
drmKeysLoadedevent - Add two new events (
drmKeyRequestStarted,drmKeyRequestCompleted)
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.
Activity
stevemayhew commentedon Jan 19, 2024
@icbaker I'm curious why
DefaultDrmSession.RequestHandlerwas even implemented rather than using the existingcom.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 commentedon Feb 8, 2024
Not sure if this is what you meant, but to be explicit: you can add a
TransferListenerto theDataSource.Factoryyou pass toHttpMediaDrmCallback, and you should get some callbacks including URLs etc.Good question - I'm afraid I don't know the reasoning at the time, but I suspect it might have been felt that the
Loadermachinery 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).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 newonDrmKeysLoaded(int, MediaPeriodId, KeyLoadInfo)method (type name TBD). You will want to ensure that both are invoked fromDrmSessionEventListener.EventDispatcher.drmKeysLoaded. Similar onAnalyticsListener(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.drmKeysLoadedmethod to take the newKeyLoadInfotype without deprecating the zero-arg overload, since direct usages of that are probably quite rare (customDrmSessionManagerimpls only really) - and maintaining both becomes tricky (since you have to synthesise a 'fake'KeyLoadInfowhich is a bit confusing).stevemayhew commentedon Feb 23, 2024
Thanks, yes the method
DrmSessionEventListener.EventDispatcherdrmKeysLoadedOis public, but not really an API so adding theKeyLoadInfoobject should not be a problem. We'll work on the pull request.Adds load info to `DrmSessionEventListeneronDrmKeysLoaded()`
stevemayhew commentedon Feb 26, 2024
@icbaker Here's the pull request with first pass: #1134
I need to plumb through to
AnalyticsListenerin order for it to be useful, wanted to stop before I got to far and get your feedback.You should have access to my repo if you want to suggest changes in code feel free to branch and make pull requests, add commits, or just comment on the pull
THanks!
Adds load info to `DrmSessionEventListeneronDrmKeysLoaded()`
Adds load info to `DrmSessionEventListeneronDrmKeysLoaded()`
Adds load info to `DrmSessionEventListeneronDrmKeysLoaded()`
Adds load info to `DrmSessionEventListeneronDrmKeysLoaded()`
Adds load info to `DrmSessionEventListeneronDrmKeysLoaded()`
feat: m3u headers(androidx#1001)
feat: m3u headers(androidx#1001)