Issues when loading persistent licences on singleLicensePer: "content" mode
#1031
Assignees
Labels
DRM
Relative to DRM (EncryptedMediaExtensions)
Priority: 1 (High)
This issue or PR has a high priority.
Milestone
Comments
peaBerberian
added a commit
that referenced
this issue
Jan 21, 2022
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.
peaBerberian
added a commit
that referenced
this issue
Jan 21, 2022
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.
peaBerberian
added a commit
that referenced
this issue
Jan 21, 2022
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.
peaBerberian
added a commit
that referenced
this issue
Jan 21, 2022
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.
peaBerberian
added a commit
that referenced
this issue
Jan 21, 2022
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.
peaBerberian
added a commit
that referenced
this issue
Jan 24, 2022
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.
peaBerberian
added a commit
that referenced
this issue
Jan 24, 2022
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.
peaBerberian
added a commit
that referenced
this issue
Jan 24, 2022
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.
peaBerberian
added a commit
that referenced
this issue
Jan 28, 2022
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.
peaBerberian
added a commit
that referenced
this issue
Jan 28, 2022
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.
peaBerberian
added a commit
that referenced
this issue
Feb 17, 2022
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.
peaBerberian
added a commit
that referenced
this issue
Mar 16, 2022
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.
|
Fixed while #1056 was merged. |
peaBerberian
added a commit
that referenced
this issue
Mar 17, 2022
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.
Merged
peaBerberian
added a commit
that referenced
this issue
Mar 18, 2022
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Issues when loading persistent licences on
singleLicensePer: "content"modeWhile working with application developers at Canal+, I noticed that several issues could arise when relying on both persistent licenses and licences containing the keys for all the content and not just the asked key (what we call
singleLicensePer: "content"- from the option of the same name - in the RxPlayer team).Problem 1: reloading a single-key license on
singleLicensePer: "content"modeThe problem we actually encountered was due to a switch made in the corresponding application from a
singleLicensePer: "init-data"(basically meaning here a single key per license) mode to asingleLicensePer: "content"mode (all content keys in a single licence), while license from the previous mode were persisted.Here, when playing contents encrypted with multiple keys, the RxPlayer could load an old single-key license while thinking it is actually loading a multi-key license (it only bases itself on the
singleLicensePeroption set on the current loadVideo). Consequently, all other keys not present in that single-key license would be considered as not usable.In the tested case, it meant that we could not load the corresponding video.
A simple and ugly application-side solution could be to empty the data saved in the "
licenseStorage" argument, thereby emptying all knowledge about persistent licenses, when doing the"init-data"->"content"transition.Though a more durable solution could be to add to the persisted data the notion of the
singleLicensePerargument (or something related to that). That way, insingleLicencePer: "content"mode, we would always load licenses linked to previous contents also loaded with thesingleLicencePer: "content"mode (and never those with the"init-data"mode).This method looks nice but will invalidate all
singleLicensePer: "content"license persisted before the RxPlayer version bringing the fix.It also has a second issue, kind-of linked to the "problem 2": we risk loading the wrong license if multiple
singleLicensePer: "content"licenses exist with keys in common. This issue may become more clear after reading the "problem 2", and the solution provided at the end of it should remove this problem anyway.Problem 2: Only one set of init-data is stored even in
singleLicensePer: "content"A second potential problem that could arise when both
singleLicensePer: "content"mode and persistent licenses are used is linked to the fact that the RxPlayer is still only storing the init-data relative to the first asked key, even if, in fine, the license contains decryption keys for the whole content.Basically this means that if we re-load the content by beginning to play video or audio qualities encrypted with a different key than what we initially played while previously loading that content, we will re-fetch the license - even if the previously-loaded license actually should already contain that key.
Said in another way: if the initial init-data (which are in most cases ISOBMFF PSSH boxes) encountered is different, the RxPlayer will not be able to retrieve a stored license.
Where this is a perfectly normal and functional logic in
singleLicensePer: "init-data"mode, it is not insingleLicensePer: "content"mode, where we would like to be able to re-load the license even if another key for the same content is initially needed.Sadly, this is a much more complex issue than the first one.
The first naive solution we could think of is just storing all key-ids linked to a persistent license and re-loading the latter as a
singleLicensePer: "content"mode license as long as the initially wanted key-id match but here we would have several issues:what about keys implicitly not usable because not present in the license (example: Widevine L1 keys for a L3 device)? Here we would not be able to retrieve the stored license if this is the first key we need.
We could also add such "non-usable" keys to the stored entry but all those keys might not be known initially (example: for a live contents with new key-ids only anounced in the future).
more importantly, what if a common key is used on multiple different
singleLicensePer: "content"contents which have each different combinations of keys?How do we know if we're re-loading the license for the right content and not one initially-fetched for another content with less keys than what we need now?
To me, a possible solution would be to:
singleLicensePer: "content"mode store in the persisted license entry all known key-ids (or init-data) both in the current content and in the current license (or more technically, linked to the correspondingMediaKeySession).singleLicensePer: "content"mode, check the current key-id in the storage each time a new one is encountered in the content. Here, there could be the following situationsFrom that point, we will link that fetched license to all key-ids present and future in that current content (because we're in
singleLicensePer: "content"mode), so we should not need to load persistent session nor doing license request for the currently-played content.The text was updated successfully, but these errors were encountered: