-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Robustness warning in Chrome? #518
Comments
We already support robustness settings. See "Advanced DRM Configuration" in the DRM Configuration tutorial. We don't set robustness by default because that would require us to hard-code knowledge of valid robustness levels, which are not defined in the EME spec. Each key system has its own set of valid robustness strings. |
The message is ominous, though. For now, the empty string is allowed by the EME spec and is meaningful:
We'll keep an eye out for changes on this. Perhaps the message references an older version of the spec in which this was not well defined. |
See also this text (emphasis added) from the note following the normative text above:
This warning is for the current version of the spec and related to potential changes to Chrome (or other implementations) that could break some apps that do not provide a robustness level. For example, the lowest supported level is often not appropriate for video. |
Ah, I see. Thanks for the correction, David. |
All right! Thanks for the clarifications. While reading I thought of another argument to not provide a default: EDIT: Unless a high level robustness doesn't lead to more effective DRM, in which case my point is moot. |
Just in case someone is looking for the information, to get rid of the warning, I used |
Have we answered this question to everyone's satisfaction? Can we close it? |
I'm satisfied, thanks. You can close it. |
@joeyparrish I am using shaka 2.02 and set robustness level to
|
@Zorig, are you using the demo app or a custom app? If custom, are you using |
@joeyparrish I am using custom app(Ember 2.10) also i used probeSupport like this. Is it wrong usage?
|
Ah, that makes sense now. The warning is triggered by |
okay, @joeyparrish so how should i set robustness in this case? checking widevine is essential in my case. And some drm songs are not playing because of robustness i think |
I'm not sure I understand the question. You don't need to set robustness in any way to call |
Some of my songs are not playing. So i thought it is because of robustness level according to warning. And when i set robustness level it still gives me robustness warning |
I got the same error on basic code. It's triggered by navigator.requestMediaKeySystemAccess method used to test if certain key system is supported: var config = [{
"initDataTypes": ["cenc"],
"audioCapabilities": [{ "contentType": 'audio/mp4;codecs="mp4a.40.2"' }],
"videoCapabilities": [{ "contentType": 'video/mp4;codecs="avc1.42E01E"' }]
}];
try {
navigator.
requestMediaKeySystemAccess("com.widevine.alpha", config).
then(function (mediaKeySystemAccess) {
console.log('widevine support ok');
}).catch(function (e) {
console.log('no widevine support');
console.log(e);
});
} catch (e) {
console.log('no widevine support');
console.log(e);
} Add robustness level setting to config object solved the problem: var config = [{
"initDataTypes": ["cenc"],
"audioCapabilities": [{ "contentType": 'audio/mp4;codecs="mp4a.40.2"', robustness: 'SW_SECURE_CRYPTO' }],
"videoCapabilities": [{ "contentType": 'video/mp4;codecs="avc1.42E01E"', robustness: 'SW_SECURE_CRYPTO' }]
}]; Besides, this warning only triggered when key system is "com.widevine.alpha". Add robustness setting to other key system like PlayReady and ClearKey causes exception and returns false negative result:
|
When initiating a stream in shaka2 you get an ominous warning in the console:
It is recommended that a robustness level be specified. Not specifying the robustness level could result in unexpected behavior in the future, potentially including failure to play.
.This is probably benign, but if it can be mitigated somehow, that would be great. I saw a PR merged earlier this summer in dash.js that seems to deal with this issue, (Dash-Industry-Forum/dash.js#1446) maybe that could be of interest.
The text was updated successfully, but these errors were encountered: