Re: Encrypted Media proposal: Summary of counter-proposals

On 3/9/12 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.

I've posted my recommendation that a real baseline be specified in the 
EM proposal, simply using the websockets masking key technique.

I agree that the proposal is incomplete. However, the "main problem" 
with the proposal from what I've seen of the push-back is that it's 
based on supporting DRM.

This is the "do not want" issue for many of the people posting here:

"The second level is for HD content, Netflix's 'premium' level. Here, 
Netflix is forced to have a much more rigorous set of requirements so 
that it can fulfill contractual agreements with its content parners. To 
playback HD content, the entire end-to-end chain must be DRM-enabled, at 
no point in the playback datapath can the video stream be unprotected. 
That means decoded and uncompressed frames, audio, and device secrets 
must only exist in 'firewalled,' protected memory that the OS can't get 
access to, the decoder can only exist in a trusted execution 
environment, and HDCP must be used for the stream to be output over HDMI"
http://www.anandtech.com/show/4480/ti-omap4-first-to-be-awarded-netflix-hd-1080p-hd-sri-certification

> 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.

CDMs are potentially incompatible regardless; again, we have that with 
codecs, we'll have it with CDM. It's an abstracted interface.

Yes, we should have a baseline CDM. We should get open documentation 
about what the API hooks are for existing CDMs.

We're going to have incompatibility, that's just the way it is. At least 
with a baseline, we'll have one standard that can be implemented in open 
source, royalty-free and so forth. And we may be able to get some kind 
of patent release/protection around it. From that baseline, we can see 
what trickles into open source repos.


-Charles

Received on Friday, 9 March 2012 16:20:14 UTC