[Bug 25092] Need a way to inform script that resolution restrictions are applied

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25092

--- Comment #29 from David Dorwin <ddorwin@google.com> ---
I see agreement that we should differentiate. I also agree with Joe's (comment
26) and the Mark's (first paragraph of comment #27) description of usage.
At a minimum, that means adding "[output-]downscaled" to MediaKeyStatus as I
proposed in comment 25. This is consistent with how we decided to support
output protection (HDCP) errors.


Mark's objection to a MediaKeyStatus value seems to be that they have policies
that differ by resolution rather than key ID. I would expect this to be rare in
practice. The current solution supports both mechanisms.

Key IDs are a first-class and normative concept in EME. Policies, output
protection, and resolution are not. If we expose resolution information, it's
logical to want to expose HDCP versions and other policy details.

The current solution is based on an existing first-class concept and provides a
clear and simple mechanism for applications to get the information that only
the CDM has. For example, "The output protection policy for key ID X cannot be
met. Therefore, the CDM will {block playback | downscale video} if media data
with that key ID is encountered." Given this information, the application knows
it should avoid/stop fetching streams that use key ID X. In the former case,
the application may need to fetch a new stream for the current playback
location.

Applications can then build complex logic upon this basic functionality, using
different key IDs if necessary. If necessary, the application can obtain
additional information, such as associated policies or a mapping of key ID to
stream (some type of mapping of policy to stream is necessary in any solution),
from the server.

By contrast, an event or other more specific mechanism would likely be complex
and/or be restricted in the scenarios it can support. For example, it would
need to support reporting multiple resolutions with different behaviors
(blocked and downscaled), report which policies/keys are affected, and report
this information without having played the content (see below). This would also
add interoperability risk because client implementations would need to expose
all this data, which may not be consistently available or implemented in
various CDM implementations.

The current simple mechanism minimizes the API surface and allows authors to
build complex applications with whatever policy combinations they wish.


(In reply to Mark Watson from comment #27)
> So, this solution forces us to associate multiple key ids with the same key
> in order to express the distinct policies.
How much of a burden is this the extra key ID? I don't think there is actually
any association - you would always use the same key ID for the "high
resolution" policy.

> Worse, the association of policy
> to key ids is done in a completely undefined way (which will thus probably
> differ between CDMs).
How is it undefined? As with "real" key IDs, the application and its server set
policies for the key and the CDM reports whether they are enforcable.
> 
> It would be cleaner, now that the CSS discussion has concluded this is not a
> subset of a more generic requirement, to simply have explicit output
> protection events.
One important goal of the current solution was to allow the status to be
exposed without trying (and potentially failing) to play content. Thus, adding
an event that is fired when content is downscaled or cannot be output is
insufficient.
While  a downscaling event may work for your single-key use case, it seems it
would either not be extensible to more complex cases or require a lot more
complexity to support them.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 16 January 2015 18:15:11 UTC