-
Notifications
You must be signed in to change notification settings - Fork 133
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
[Proposal] DRM: Add keySystems[].wantedSessionTypes
loadVideo
option
#1604
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
peaBerberian
added
DRM
Relative to DRM (EncryptedMediaExtensions)
proposal
This Pull Request or Issue is only a proposal for a change with the expectation of a debate on it
labels
Dec 12, 2024
peaBerberian
added
the
Priority: 2 (Medium)
This issue or PR has a medium priority.
label
Dec 23, 2024
peaBerberian
added
Priority: 1 (High)
This issue or PR has a high priority.
and removed
Priority: 2 (Medium)
This issue or PR has a medium priority.
labels
Jan 8, 2025
peaBerberian
force-pushed
the
feat/wanted-session-types
branch
from
January 10, 2025 13:48
679bc6c
to
93b28fe
Compare
Problem ------- We encountered a complex case with an application where they want to be able to load some contents relying on temporary licenses (the decryption kind) and others relying on persistent licenses, yet still keep our "`MediaKeySession` cache" intact when doing that (which would in the end contains both types). The main issue with that usage was linked to our API: - When an application wants to load a content with a persistent license, it will set in its `loadVideo` call our `keySystems[].persistentLicenseConfig` option, which would set both: - the EME configuration's `persistentState` requirement to `"required"` - unless the `keySystems[].persistentState` option is explicitly set to something else, and - the `sessionTypes` configuration property to `["temporary", "persistent-license"]` (NOTE: so able to handle both kinds, weirdly, not sure why we ask for both, it seems to be a mistake here - maybe for another PR). - When an application wants to load a content with temporary licenses, it will not set the `keySystems[].persistentLicense` option, and consequently: - the `persistentState` would be set to `"optional"` -unless the `keySystems[].persistentState` option is explicitly set to something else, and - the `sessionTypes` configuration property is set to just `["temporary"]` Those results lead to non-compatible `MediaKeySystemAccess` instances which means that going from content with temporary licenses to contents with hpersistent ones and vice-versa is going go lead to the re-creation of a `MediaKeySystemAccess` behind the hood at content load. In turn, this `MediaKeySystemAccess` change is going to internally reset the `MediaKeySession` cache we keep to avoid doing license request if we already requested it recently. Note that this is the only known issue of switching `MediaKeySystemAccess` here. For cases where that cache is not important, there should be no much of a problem to create another `MediaKeySystemAccess` (beside perhaps performance issue on really really slow implementations). Solution proposed here ---------------------- To fix that very specific issue, I propose here the `keySystems[].wantedSessionTypes` `loadVideo` options, which would be explicit about the `sessionTypes` we want the created `MediaKeySystemAccess` to handle. With that and `keySystems[].persistentState`, an application should be able to ask for every capabilities it needs the `MediaKeySystemAccess` to be able to do, without necessarily having to link it to the current content. As this is a very technical need, I had a lot of trouble in making the API approachable in the documentation, I spent a lot more time writing the few lines in the documentation than actually implementing this! I'm also afraid that most applications won't understand the point of that API, even at project at Canal+, as it is very linked to both the EME recommendation and the RxPlayer internals (its `MediaKeySession` cache).
peaBerberian
force-pushed
the
feat/wanted-session-types
branch
from
January 10, 2025 14:40
93b28fe
to
c76324a
Compare
Florent-Bouisset
approved these changes
Jan 10, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
DRM
Relative to DRM (EncryptedMediaExtensions)
Priority: 1 (High)
This issue or PR has a high priority.
proposal
This Pull Request or Issue is only a proposal for a change with the expectation of a debate on it
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
We encountered a complex case with an application where they want to be able to load some contents relying on temporary licenses (the decryption kind) and others relying on persistent licenses, yet still keep our "
MediaKeySession
cache" intact when doing that (cache which would in the end contains both types).The main issue with that usage was linked to our API:
When an application wants to load a content with a persistent license, it will set in its
loadVideo
call ourkeySystems[].persistentLicenseConfig
option, which would set both:the EME configuration's
persistentState
requirement to"required"
- unless thekeySystems[].persistentState
option is explicitly set to something else, andthe
sessionTypes
configuration property to["temporary", "persistent-license"]
(NOTE: so able to handle both kinds, weirdly, not sure why we ask for both, it seems to be a mistake here - maybe for another PR).When an application wants to load a content with temporary licenses, it will not set the
keySystems[].persistentLicense
option, and consequently:the
persistentState
would be set to"optional"
-unless thekeySystems[].persistentState
option is explicitly set to something else, andthe
sessionTypes
configuration property is set to just["temporary"]
Those results lead to incompatible
MediaKeySystemAccess
instances which means that going from content with temporary licenses to contents with persistent ones and vice-versa is going go lead to the re-creation of aMediaKeySystemAccess
behind the hood at content load.In turn, this
MediaKeySystemAccess
change is going to internally reset theMediaKeySession
cache (the one we keep to avoid doing license request if we already requested it recently).Note that this is the only known issue of switching
MediaKeySystemAccess
here. For cases where that cache is not important, there should be no much of a problem to create anotherMediaKeySystemAccess
(beside perhaps performance issue on really really slow implementations).Solution proposed here
To fix that very specific issue, I propose here the
keySystems[].wantedSessionTypes
loadVideo
options, which would be explicit about thesessionTypes
we want the createdMediaKeySystemAccess
to handle.With that and other options like
keySystems[].persistentState
, an application should now be able to ask for every capabilities it needs theMediaKeySystemAccess
to be able to do, without necessarily having to link it to the current content (e.g. it could ask theMediaKeySystemAccess
to be compatible with persistent licenses, even if the current content rely on temporary ones).As this is a very technical need, I had a lot of trouble in making the API approachable in the documentation, I spent a lot more time writing the few lines in the documentation than actually implementing this!
I'm also afraid that most applications won't understand the point of that API, even application developers at Canal+, as it is very linked to both the EME recommendation and the RxPlayer internals (its
MediaKeySession
cache).