Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
DRM: re-implement
singleLicensePer
handling
This update is build on the DRM refacto started in #1042 and fixes some of (complex, yet relatively minor) performance issues that could be encountered in a `singleLicensePer: "content"` mode. It also paves the way for the future `singleLicensePer: "periods"` mode. In particular, it does the following things: Optimization on the in-memory MediaKeySession cache when in `singleLicensePer: "content"` mode ----------------------------------------------------------- The in-memory cache of MediaKeySessions presented by the `LoadedSessionsStore` - which basically allows faster loading of already-loaded content by re-using a recently-created MediaKeySession before relied only on the initialization data for identification purposes. This means that false negatives can occur (in that: cache miss where it should have been a hit) in the `singleLicensePer: "content"` mode (which implies that a single license request will actually retrieve all keys linked to the content), if when re-loading the content a different initialization data is initially encountered. This would be a false negative here because even if this is different initial initialization data than before, the already-created MediaKeySession still should have received the key to decrypt that other quality. This is now fixed by linking a MediaKeySession in that cache both to the initialization data linked to it and to all key ids that are explicitely (i.e. in the fetched license) AND implicitely (i.e. in the Manifest file when in a `singleLicensePer: "content"` mode yet not in the license) linked to it. This is done through the declaration of a new structure, the `KeySessionRecord`, which can be "associated" to supplementary key ids at any time, and which contains an `isCompatibleWith` method to quickly check if newly encountered initialization data and/or key id is actually compatible to an already-created MediaKeySession. MediaKeySessions loaded (persisted ones) AND retrieved from our memory cache now are not subject to the `singleLicensePer` option. ---------------------------------------------------------------------- All persisted MediaKeySessions as well as all those kept in our in-memory cache were before subject to the same `singleLicensePer` rules than the current content that is being loaded. This means that technically, a license fetched for a previous content in a `singleLicensePer: "init-data"` mode (the default), could be wrongly inferred to be a `singleLicensePer: "content"` one if a new content compatible with it was loaded in that mode. This would result in the impossibility to use more than the one key stored with that MediaKeySession. This issue is described by the problem 1 of the #1031 issue (note that problem 2 is not yet fixed, though it is a work-in-progress). To fix this, the RxPlayer does now two things: 1. A cached or persisted (still in WIP for that second one) MediaKeySession will now be linked in the corresponding cache to all known key id that are linked to it either implicit or explicit (description of both term higher in this message). 2. Only MediaKeySessions receiving fetched license will now follow the `singleLicensePer` rule, all other type of sessions (loaded or retrieved from cache) will only be linked to the key id known at the time the caching has been done. This could mean relatively rare false negatives when a re-loaded content in a `singleLicensePer: "content"` mode contains key ids previously unheard of, but it is still the safest solution. Write skeleton for the future `singleLicensePer: "periods"` ----------------------------------------------------------- One of the goal of that big implementation was also to pave the way for more complex `singleLicensePer` modes, as we plan to do for the v3.27.0 (#1028). The main differences are that the `ContentDecryptor` (the new `EMEManager`) now also receives Manifest-related structures in the initialization data emitted to it and perform all the blacklisting by itself. This allows it to e.g. know about implicit key ids (keys that should have been in the license according to the `singleLicensePer` mode but which aren't) without necessitating a round-trip with the Init module. Remaining issues ---------------- One unfortunate side-effect of the current implementation, is the creation of a lock to only allow one initialization data at a time until either the right MediaKeySession is obtained (either created, loaded, or retrieved from cache) in `singleLicensePer: "init-data"` mode or until the license's keys are available in singleLicensePer: "content"` mode. This could mean unnecessary waiting when a persistent MediaKeySession is being loaded, and even more when we have troubles loading it - which is a frequent occurence on some set-top-box. I'm sure that we could write a less strict lock though, I just didn't take the time to do it. Another remaining issue is that I did not finish working on persisted MediaKeySession here, most notably to fix the problem 2 exposed by the #1031 issue.
- Loading branch information