[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 #30 from Mark Watson <watsonm@netflix.com> ---
Ok, let's agree on "downscaling" as a new key status.

Nevertheless, pls see comments below. In summary, we can't require that the
policy associated with a key id is independent of content properties. It's
already very common to have policies that are content property dependent. So,
key status can change as content properties change.

This means that you can't learn that content will be downscaled until you feed
some content in, but we can live with that for the moment (I believe there are
other reasons why that is the case anyway).

If, instead, we wanted the key status to be content-independent, we'd need the
status to be a map of resolution -> status.

(In reply to David Dorwin from comment #29)
> 
> 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.
> 

I don't think this will be rare. It will be common to have a single key / key
ID with a policy that says, for example, that different HDCP versions are
needed for different resolutions.

However, I agree that the "downscaling" / "not allowed" key statuses can work
for this use-case: the application will need to know what the resolution
constraints are and work downwards in resolution until a working stream is
found. 

> 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.

I'm not sure that follows: I'm interested in having the relationship between
resolution and key status exposed, to avoid the trial-and-error. That doesn't
mean the full mechanics of that relationship are needed (e.g.HDCP details),
only that I can see which resolution maps to which status at the current time.
But in advance of UHD there is only one other resolution to try, so I'm happy
to punt on this for now.

> 
> 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.

I don't think we can assume that a single Key ID has a simple met / unmet
policy, independent of content properties like resolution. The status must
indicate the action being taken for the media data available at the present
time (for that key ID) and may change if the properties of the media change.


> 
> (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 enforceable.

If you are using separate keys with separate policies and the policies are all
content-independent and the CDM supports such multiple keys in one session,
then everything is fine.

But there are CDMs that support only a single key or only a single key at a
time. And there are CDMs that support content-dependent policies. These CDMs
would probably need modification to expose multiple key ids associated with the
same actual key, corresponding to splitting up the policy by content property
such as resolution. How that is done - what those extra key ids would be etc.
is undefined (CDM-specific).

We need first-class support for the case of policies that are dependent on
content properties, since this is going to be common. The proposed key status
values do provide this, albeit in a limited form.

> > 
> > 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.

That's a good goal, but it is not supported by the proposed key status values,
since there is no way to expose the content-dependent aspects of the policy for
a single key id.

> 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 Monday, 19 January 2015 16:53:05 UTC