[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 #17 from Mark Watson <watsonm@netflix.com> ---
(In reply to David Dorwin from comment #16)
> (In reply to Mark Watson from comment #15)
> > Ok, let me check I understand how this would work:
> > 
> > The license would contain the key and its true key ID, matching the key ID
> > in the content files. The license would also contain policy for resolution
> > restrictions and one or more 'fake' key IDs corresponding to different
> > resolution levels. The client side of the app knows these fake Key IDs
> > correspond to resolution levels.
> 
> They really correspond to policies, which the application may further map to
> resolution levels.
> 
> > The new API would expose the key IDs, both the fake ones and the real one
> > (or possibly just the fake ones ?).
> 
> All key IDs would be exposed - the CDM doesn't know about fake key IDs. In
> the downscaling case, the real key ID would always be "usable".

The CDM would need some way to associate the right fake IDs with the right
files. Since we do not have the fake IDs embedded in the files, this can only
be through the CDM understanding indications in the license that say 'this key
ID is for files with resolution < X' together with the resolution indications
in the file.

> 
> > The CDM would signal changes in
> > resolution restrictions as changes in the usable key IDs.
> 
> Yes, The CDM would indicate whether the whether all of the reasons to
> restrict resolution are false (fake key ID is listed as usable) or not (fake
> key ID not listed as usable)

It's not necessary boolean. Sometimes you may be restricted to SD and sometimes
to HD.

> 
> > Did I get this right ?
> > 
> > Seems like a real kludge where the key IDs are being abused to represent
> > different policies that may or may not be applied. The fake Key Id is really
> > a 'policy identifier' and the 'usablekeyschange' is being abused to indicate
> > a policy change.
> 
> In the single key ID case, it is. This is really a case of using a general
> purpose API (bug 25409) for a specific use case.

Seems like you are assuming a particular 'ideal' approach in which each stream
has a separate Key Id and then working backwards to say that if that is not the
case the CDM and application need to 'fake out' that ideal approach.

But it is very awkward, which suggests to me that this general mechanism,
whilst potentially useful for other things, isn't right for this usecase.

> 
> EME relies on and exposes a few basic concepts, including sessions and key
> IDs. It doesn't expose policies, robustness, resolutions, etc. Even if we
> wanted to expose those, it would be difficult to get consistent
> definitions/behavior. A fake key ID seemed like the best way to use the
> existing common primitives to address this specific use case.

Applying restrictions is one of the things DRMs commonly do and restrictions
based on stream properties is a common class of restrictions. I think more
promising would be to look at general ways of specifying stream properties that
might be restricted (media queries ?) and also looking at whether there are
non-DRM reasons that restrictions might be applied (output capabilities?).
Again, this could fit better into MSE if there are non-DRM reasons for such
restrictions.

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

Received on Tuesday, 29 April 2014 00:41:00 UTC