Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[v3] DRM: Only check cached MediaKeySystemAccess compatibility with most wanted key system #1596

Closed

Conversation

peaBerberian
Copy link
Collaborator

This is a backport of #1591 to the v3

…anted key system

When loading a content with the RxPlayer, you can provide multiple DRM
configurations (e.g. Widevine L1, PlayReady SL3000, Widevine L3 etc.) in
a certain order of preference.

The idea is that the RxPlayer will attempt one after another and finish
with the first compatible one.

To speed up later video loading operations, the RxPlayer always re-check
at each video load operations if the last created MediaKeySystemAccess
is compatible with one of the configuration, and if it is, use that one.

However turns out that this is not always what application wants. We've
seen for example a device with both Widevine and Playready where the
application wanted Widevine in priority for some contents and PlayReady
in priority for other contents, yet always asking for both (just in a
different order of preferences for those various contents).

Due to our MediaKeySystemAccess-reusage strategy, even if PlayReady is
prioritized for a latter content and the device is compatible with it,
we could be still using Widevine because it was already the DRM system
used for the last content and because Widevine was still OK for the
application, just less prioritized.

Instead of this, this modification only reuse the "cached"
`MediaKeySystemAccess` if it corresponds to the current most wanted
configuration (i.e. it is re-checked with each iterations on the
`keySystems` option before the actual
`navigator.requestMediaKeySystemAccess` call).
@peaBerberian peaBerberian added this to the 3.33.5 milestone Nov 20, 2024
@peaBerberian
Copy link
Collaborator Author

Closing this because I personally think that #1597 might even handle more cases.

I'll backport it once/if merged

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant