Clarity regarding Robustness string in EME Spec #521
Comments
|
It may also make sense that the spec was trying to say MAY configure the CDM to use the lowest robustness level in the configuration even if a higher robustness level is available, and then lead into how when robustness is the empty string, the implementation may default to the lowest one available. In any case, this bug is for discussion so we can get some clarity over what the sentence is supposed to be. |
|
AFAICT, there is nothing specified about how robustness levels are chosen or defined. I believe a robustness level in a configuration is a minimum requirement for the application. Therefore, the CDM could provide a higher level, but never a lower one than requested. If I say "I'll take level 3000 please", the CDM may only have the DRM vendor's level 5000 available, but that's fine. It's more robust than my application's minimum requirement. The full note currently says:
I believe it should say:
I welcome everyone's feedback, but if I don't hear anything in the next couple of weeks, I'll go ahead and edit the spec accordingly and close this issue. |
|
@xhwang-chromium, @jernoble, would this make sense to y'all in particular? |
|
On one platform, we noticed that there was a problem with a specific robustness, which happened to be the highest. We wanted the CDM to be configured with the lower robustness. Using the robustness levels above as an example, we specified 3000 in the configuration. Even though the platform has 5000 available, we specifically didn’t want the CDM to use that configuration. So even though a “higher robustness level is available”, we relied on the fact that the CDM would “use the highest level in the configuration” and not higher. I think the confusion comes from the fact that the argument is a sequence of MediaKeySystemMediaCapability. |
I'm familiar with this pattern. But I'm a little unsure if we want to specify this selection behavior. I think we could, maybe with something like: "select the lowest-robustness CDM with a robustness equal to or greater than the requested robustness". Robustness strings that exist for key systems I'm familiar with are ordered. PlayReady's are actual numbers, which makes the "greater than" part clear, but Widevine's are descriptive text whose ordering is less clear without documentation from Widevine. I think we could maybe say that the exact strings and their order are key-system-specific. What we have to be careful about is that we can't simply say "highest in the configuration". We have to allow for a higher robustness to be chosen by the UA. I may have a device that only contains Widevine L1 in hardware, but no L3 software-only CDM. If I ask for
Ah, I see. So this part?
Supporting the plural levels here is confusing? I think the way "levels" makes sense is that audio and video robustness often vary. We should make the note more explicit in any case. |
|
Sorry for being late in the discussion. Pasting the current text here (from #521 (comment)) for easier reading:
My thoughts on this text:
With that, here's my understanding of the full note (all "levels" are robustness levels):
(2) doesn't rule out the possibility of "the actual level of the CDM > the highest level in the configuration", which is what's being debated in #521 (comment) and #521 (comment). @joeyparrish's argument makes sense from content security perspective, that a higher robustness level is a super set of a lower robustness level in terms content security features. But I guess @gregwfreedman is more from a stability perspective, that if a higher robustness level is less stable, the player would rather use a lower robustness level and doesn't want the "upgrade". In Chromium, we do the "auto upgrade" in one platform when we are sure that both the content security and robustness levels are better, and in the majority cases we strictly use "the highest level in the configuration" to allow the JS application to control the exact behavior. So we need to decide on whether we allow "the actual level of the CDM > the highest level in the configuration". It's probably cleaner to disallow it in the spec, but in reality we already have existing systems that are not compliant. So it's probably simpler to just allow this flexibility? |
|
We shouldn't have normative requirements in notes, so I wonder if we should take the current spec text out of the note and a new note to provide an illustrative example. |
|
Good point! Does that mean we should not have |
|
Yes, it means we shouldn't say MUST in notes, but also other RFC 2119 words (see the style guide). The Conformance section of the spec suggests lower case is OK, but I think it's better to avoid that. I suggest we review all the notes, but in a separate issue. Some of them seem to place requirements on authors (which relates to #531). |
In the meeting, we agreed to drop point 2, which is a logical implication of point 1. If X must be >= Y, X may be == Y. We also agreed to move point 1 to normative text. Point 3 can be an explanatory note. I'll make a PR. |
In the EME Spec, it currently states
Exact configuration of the CDM is implementation-specific,and implementations MAY configure the CDM to use the highest
robustness level in the configuration even if a higher robustness level is available.
On reading this,
MAY configure the CDM to use the highest robustness level in the configuration even if a lower robustness level is available.
This second sentence makes a little more sense to me, since highest -> higher doesn't add up.
The text was updated successfully, but these errors were encountered: