-
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.
DRM: Refacto implementation selection mechanism
While debugging a safari issue that in the end seemed link to both DRM and audio track selection of a directfile contents, we experimented with the possibility for an application to choose between EME implementation. For example, an application could decide on Safari to either rely on the latest EME recommendation or on the still-available webkit-vendored API, which are both incompatible to one another. This was a feature we didn't really want, but what we thought we might have to implement because Safari had issues with both API that could lead to the impossibility to play the content, but the RxPlayer couldn't determine which content would work best with which API, but the application could (as it depended on the packager used). Thankfully, we ended up finding a better solution, relying only on timing audio track switches requests on the application-side instead. Still, we had the feature ready and though this new API appears unnecessarily complex now that we don't need it anymore, some work on it still appear beneficial to the RxPlayer. Consequently, this commit removes any notion of the new API but keeps: - EME polyfills (webkit-vendored and so on) are now only brought into your application when you rely on the "minimal build" if you actually import the `EME` feature (it makes sense, shouldn't break anything, and just remove some code from your bundle(s) if you don't need decryption) - The choice of the EME implementation to rely on is now isolated in its own `getEmeApiImplementation` function based on an implementation's "name", instead of just chosen once at evaluation time, which should make future debugging easier. - MediaKeys-related clean-up is now always performed with the EME API that was used for the corresponding content. - The webkit implementation now only rely on the `webkitneedkey` event for initialization data and not on the `encrypted` event anymore, as its format is different. - Switching EME implementation between contents is now a possibility, and we clean-up the previous implementation's side effect when we do so. - We remove the potentiality of a race condition between `setMediaKeys` EME API call by awaiting the returned promise when we're removing the previous MediaKeys instance. - Some minor `ContentDecryptor` improvements, brought initially when we wanted to attach MediaKeys to the HTMLMediaElement only _AFTER_ the encrypted events - which is not needed now - but the modifications appeared to lead to a simpler architecture that what we had before.
- Loading branch information
1 parent
e80e99a
commit 049201a
Showing
53 changed files
with
1,057 additions
and
849 deletions.
There are no files selected for viewing
This file was deleted.
Oops, something went wrong.
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.