Re: Encrypted Media proposal: Summary of counter-proposals

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) and 
the APIs between those CDMs and browsers.  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 10:22:27 UTC