Re: Encrypted Media proposal: Summary of counter-proposals

On Mar 9, 2012, at 2:21 AM, Lachlan Hunt wrote:

> On 2012-03-09 00:24, Charles Pritchard wrote:
>> On 3/8/2012 1:44 PM, Tab Atkins Jr. wrote:
>>> On Thu, Mar 8, 2012 at 12:45 PM, Charles Pritchard<chuck@jumis.com>
>>> wrote:
>>>> video.getContext('experimental-ecmd').generateKeyRequest("org.w3.clearkey",
>>>> null);
>>>> "Encrypted Media Context Draft".
>>> 
>>> This doesn't appear to address virtually any of the problems that have
>>> been raised with the DRM proposal.
>> 
>> It moves the DRM proposal out of HTML. That seems to be the main problem.
> 
> No. That's not the main problem. All you're doing is adding an additional layer of abstraction into the JS API.  Whatever object is returned by getContext() still needs to have its API defined somewhere, and with this you're opening up the possibility of an extension point for a whole range of plugins, and potentially even CDM specific APIs, which just makes things a whole lot worse.
> 
> Overall, you're proposal does nothing to address the problems raised by implementers about the undefined integration points between browsers and CDMs.
> 
> Solutions to the current deadlock in this discussion must involve defining exactly what responsibilities are to handled by a CDM (whether that simply includes decryption of encoded frames; decryption and decoding of frames; or decryption, decoding and rendering of frames)

I think we can and should do that in the document. All three possibilities should be included.

> and the APIs between those CDMs and browsers.

This is up to browser implementors, but if the early implementors of this would like to get together and agree on a common API that would be great. At least for the 'north' side of the CDM this should not be too difficult - at Netflix we have been through several iterations of such APIs with device vendors and could certainly provide the results of that experience to anyone who is interested.

>  To have the possibility of all three alternatives without a defined plugin-API makes the implementation far more complex; makes QA more difficult for ensuring that the implementation works as intended for all possible CDM approaches; makes CDMs for different browsers potentially incompatible, leading to a situation where CDM vendors develop for some browsers but not others; not to mention all the other problems that have been raised by Philip and others throughout the discussion.
> 
> -- 
> Lachlan Hunt - Opera Software
> http://lachy.id.au/
> http://www.opera.com/
> 
>

Received on Friday, 9 March 2012 17:09:22 UTC