-
Notifications
You must be signed in to change notification settings - Fork 33
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
Conditional support of encryption mode #100
Comments
Sounds good to me. I'm adding a "keySystemConfiguration" to MediaCapabilities in PR #101. Will do similar for encryption mode. @joeyparrish is this something your implementing in rMKSA for Chrome? |
@chcunningham It doesn't appear that this ever landed. Is this still on your todo list? Happy to help here if needed! |
@scottlow, this is still on my list. Its easy to implement, but I recently realized the dictionary current shape doesn't support it well (cc: @mounirlamouri). In EME, MediaKeySystemEncryptionScheme is added to the MediaKeySystemMediaCapabilitiy alongside robustness and contentType.
In MC, we already had audio and video contentType described in the Audio|VideoDecodingConfiguration dictionary, so we opted to just add the robustness string from the EME dict to our MediaCapabilitiesKeySystemConfiguration as audio|videoRobustness. Now that the EME dict also includes encryptionScheme I want to reconsider the pattern of audio|video* prefixed attributes ... its ugly. Here's a strawman that moves in the direction of bucketing audio and video things more logically. Thoughts?
|
Agreed with wanting to move away from audio/video prefixes as the EME dict grows. This seems like a sound change to me! @mounirlamouri, do you have any other thoughts here? |
I don't have a strong opinion between prefixing and creating a new dictionary but maybe if we create a dictionary, it could be It would look like: {
type: 'media-source',
audio: {
[...]
},
video: {
[...]
},
keySystemConfiguration: {
audio: {
robustness: ...,
encryptionScheme: ...,
},
video: {
robustness: ...,
encryptionScheme: ...,
}
}
} |
Thats fine with me. I'll send a PR shortly. |
"Shortly"... sorry about the wait. I started coding this up and discovered the reason Chrome hasn't shipped the current proposal (from the explainer) is due to some ergonomics concerns. I'm working to get those published and sorted out. Expect another update by EOW. |
Ok, so the issues are published (were already actually) here https://github.com/WICG/encrypted-media-encryption-scheme/issues (those filed by David are what we're spinning on internally). One of those has a PR already Some of the others have a harder path forward. I'm told Joey will try to squeeze some time in for this next week. |
We previously prefixed robustness dict-members with 'audio' and 'video'. We now nest them under audio/video dicts to allow for more elegant expansion of audio/video-specific fields alongside robustness. Ex: encryptionScheme. See #100.
We previously prefixed robustness dict-members with 'audio' and 'video'. We now nest them under audio/video dicts to allow for more elegant expansion of audio/video-specific fields alongside robustness. Ex: encryptionScheme. See #100.
It looks like |
That's correct :) |
The PR for EME encryptionScheme just landed today: w3c/encrypted-media#457 |
See w3c/media-capabilities#100 The top-level export name now reflects the fact that there are two polyfills being installed. This is a breaking change, so we bump the version number to 2.0.0. Closes #1
@joeyparrish has begun to address this issue here: https://github.com/WICG/encrypted-media-encryption-scheme/blob/master/explainer.md. There are four modes of common encryption, ‘cbcs’, ‘cbc1’, ‘cenc’ and ‘cens’. A UA may support ‘cbcs’ but not ‘cenc’ – but it is also true it might only support ‘cbcs’ applied to a particular media profile/codec – so it is the combination of encryption mode and media type that needs to be asked about – the same problem as with Supplemental Data.
The text was updated successfully, but these errors were encountered: