[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 #9 from David Dorwin <ddorwin@google.com> ---
(In reply to Mark Watson from comment #8)
> (In reply to David Dorwin from comment #7)
> > (In reply to Mark Watson from comment #6)
> > > In my usecase, the streams could all have the same key. So informing the
> > > application that a given key id cannot be used (without restrictions) won't
> > > give the application sufficient information to take meaningful action.
> > 
> > This issue was raised during the April 1 telecon. The proposal is to use a
> > fake key ID as a proxy for the policies you wish to check.
> 
> That's and additional and unnecessary requirement on the DRM - to support
> and track multiple Key Ids. Presently there are DRM systems which do not
> support multiple keys or key ids for the same session.

That's unfortunate. That's going to break interop for a lot of other use cases
too, so I'd rather focus on fixing that. In the meantime, maybe two sessions
can be used in that case or the CDMs around those DRMs can handle the second
key ID.

There are also DRM systems that don't support downscaling - something that is
much more complex than supporting multiple key IDs.

We're going to have to fix CDM limitations or make compromises (i.e. not the
perfect API) somewhere to achieve interop.

> Alternatively, this whole question could be thought of one that applies more
> generally to MSE rather than just EME. There may be reasons other than DRM
> restrictions where the resolution / color depth / frame rate etc. of the
> output is restricted (particularly, physical device capabilities) and the
> application may be interested in knowing that it could optimize by switching
> to a different stream without impacting the quality presented to the
> end-user.

That might make sense along with other TBD feature detection capabilities or on
MSE's getVideoPlaybackQuality(). However, even if the results of CDM policies
were exposed this way, the application would have to play the content (and
possibly fail) to find out the results. My proposal allows the application to
get an answer before a potentially un-playable frame is processed.

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

Received on Tuesday, 8 April 2014 22:34:46 UTC