-
Notifications
You must be signed in to change notification settings - Fork 133
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[Proposal] DRM: Add
keySystems[].wantedSessionTypes
loadVideo
option
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).
- Loading branch information
1 parent
c564bdf
commit bc8b6d6
Showing
6 changed files
with
363 additions
and
9 deletions.
There are no files selected for viewing
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
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
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
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
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
Oops, something went wrong.