[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 #34 from Mark Watson <watsonm@netflix.com> ---
(In reply to David Dorwin from comment #33)
> (In reply to Mark Watson from comment #30)
> > 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.
> 
> The key status should not change based on the content. The key status
> indicates the status of the key based on the license and environment (i.e.
> HDCP or time).
> 
> For example:
> * A key that does not require HDCP is always valid (assuming it has not
> expired, etc.).
> * A key that requires HDCP is valid if HDCP is enabled and either
> output-downscaled or output-not-allowed (depending on the client
> implementation) otherwise.
> 
> In the case where a single content key is used for all streams, the first
> key (the real one) would always report valid, and the second (fake) key
> would report whether the output protection policies for higher resolutions
> can be met.

I'll look more closely at the other bug you've filed, but as I've said above, I
really don't think the fake key id is a good approach: It's an abuse of the key
id concept for something which is really a 'slice' of a policy associated with
a single key id and I think it will be difficult to specify interoperably. We
need something better.

'output-downscaled' associated with a single key id works fine with 'binary'
content-specific policies (e.g. one policy for HD, one for SD) since the
content provider knows what that policy is and can infer that downscaling only
applies to HD, for example. It doesn't work so well for 'output-not-allowed'.

There are going to be content-specific policies associated with a single key
id, so there is ultimately a need for the CDM to slice the policy and indicate
the status of each slice against the key id in question. We could require the
slices to be ordered (in a content-provider-specified way) and then we just
need to indicate a sequence of statuses with the key id.

Anyway, we can address this in the other bug, but we may still need a
short-term solution for the binary policy associated with 'not allowed' status
(HD not allowed, SD allowed).

> > 
> > 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).
> 
> The above design enables you to determine whether content will be downscaled
> without feeding it in. This was an important part of the design as it allows
> applications to determine which streams to download without having to have
> already downloaded streams that will trigger an output protection status
> update/event/error. This was the subject of Bug 25409 ("Allow applications
> to detect whether a key is usable before using it to decrypt content"),
> which led to keyStatuses (via usableKeyIds).
> 
> The intended behavior could probably be better explained in the spec. I
> filed https://github.com/w3c/encrypted-media/issues/22. Suggestions welcome.
> > 
> > If, instead, we wanted the key status to be content-independent, we'd need
> > the status to be a map of resolution -> status.
> 
> I don't see why. The application just needs to map key IDs to streams.
> (Resolution is actually irrelevant unless it's used to select streams, but
> that is an implementation detail of the application.)
> > 
> > (In reply to David Dorwin from comment #29)
> 
> > > (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).
> 
> I filed https://github.com/w3c/encrypted-media/issues/23 for the more
> general and problematic issue of CDMs only supporting a single key. If you
> think there are additional interoperability issues or undefined behavior,
> please file additional issue(s).
> > 
> > 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.
> 
> It is supported as I explained above. It is definitely not supported if we
> rely on the properties of content processed by the CDM to change the status.

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

Received on Saturday, 24 January 2015 02:09:52 UTC