[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 #15 from Mark Watson <watsonm@netflix.com> ---
(In reply to David Dorwin from comment #14)
> (In reply to Mark Watson from comment #13)
> > (In reply to David Dorwin from comment #12)
> > > (In reply to Mark Watson from comment #11)
> > > ...
> > > > Requiring content that might be subject to restrictions such as downscaling
> > > > to have a different key id, even a 'fake' one, is arbitrary and introduces a
> > > > new system requirement (multiple key ids embedded in content) to address a
> > > > limitation of a single platform (HTML).
> > > > 
> > > > In general we should be able to play any and all content that is compatible
> > > > with the byte-stream specification, including CENC for the ISO BMFF case. We
> > > > should not introduce additional requirements on the byte-stream unless
> > > > absolutely necessary.
> > > 
> > > To clarify, the fake key ID does not need to be in the media resource
> > > ("content" and "byte-stream" above). It would only need to be in a session.
> > > Since it is fake, the same fake key ID could always be provided for all
> > > content.
> > 
> > Ok, then I am not sure how the 'fake key ID' idea is supposed to work.
> > Assuming there is no impact on the content, then if every bitrate indicates
> > the same key id in the CENC structures (PSSH, TENC) where does the 'fake' id
> > appear and how does the CDM know that this id is a synonym for the one in
> > the media files ?
> 
> Since the proposal in bug 25409 does not rely on media data, the fake key ID
> does not need to be a synonym for any of the streams. It is simply a proxy
> for a set of policies the license server has associated with that key ID.
> The application must know the implications of that key ID being usable or
> not, just as it would need to know the meaning of the originally proposed
> event.

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.

The new API would expose the key IDs, both the fake ones and the real one (or
possibly just the fake ones ?). The CDM would signal changes in resolution
restrictions as changes in the usable key IDs.

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.

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

Received on Monday, 28 April 2014 23:58:16 UTC