-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Multi-key handling #7517
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
base: master
Are you sure you want to change the base?
Multi-key handling #7517
Conversation
0540c48 to
f54efd9
Compare
Update keyUriToKeyIdMap set after KEY_LOADING
159ded1 to
1f54b01
Compare
| mediaKeySessionContext.keySystem === KeySystems.PLAYREADY && | ||
| keyIdArray.length === 16 | ||
| ) { | ||
| changeEndianness(keyIdArray); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Follow up regarding Fix issue where some devices not works with playready #7631
TODO:
Address the change made in #7631 which handles the case where keyId in keyStatuses does not require endianness to be changed.
Rather than cherry-pick #7631, consider looking for a match in mediaKeySessionContext (this might require iterating through all keyStatuses keys) and if a match is found, do not change endianness on all key status keys (ever).
An optional configuration setting that is undefined by default and only set if unset could be added to specify here whether or not to change endianness. The lookup for a match described above would only be run if this option is unset.
This PR will...
LevelKeyinstances) and their key-ids in eme-controller session-context objects.Why is this Pull Request needed?
Are there any points in the code the reviewer needs to double check?
If you've recently reported issues related to EME playback, please review and leave feedback if you are able to test. Thanks!
requireKeySystemAccessOnStartwith live #7383Resolves issues:
Checklist