W3C home > Mailing lists > Public > public-html@w3.org > March 2012


From: Sean Hayes <Sean.Hayes@microsoft.com>
Date: Fri, 9 Mar 2012 12:19:32 +0000
To: Charles Pritchard <chuck@jumis.com>, Tab Atkins Jr. <jackalmage@gmail.com>
CC: Mark Watson <watsonm@netflix.com>, Henri Sivonen <hsivonen@iki.fi>, Christian Kaiser <kaiserc@google.com>, "<public-html@w3.org>" <public-html@w3.org>
Message-ID: <E9A92BD0A4FC934EB7935470A46D15240905AA63@DB3EX14MBXC325.europe.corp.microsoft.com>
Changing the subject line so this doesn't get drawn into the DRM argument. I don’t have a dog in that fight.

However I do think that video.getContext("..") might be a great hook for supporting media accessibility features that require DSP like computations to be injected into the pipeline, such as enhance/decrease contrast, video magnifier, moving audio into frequency bands that the user can hear, removing all but the center channel and so on.

+1 to Charles' approach.

-----Original Message-----
From: Charles Pritchard [mailto:chuck@jumis.com] 
Sent: 08 March 2012 23:24
To: Tab Atkins Jr.
Cc: Mark Watson; Henri Sivonen; Christian Kaiser; <public-html@w3.org>
Subject: Re: Encrypted Media proposal: Summary of counter-proposals

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:
>> TL;DR: This document includes my TL;DR recommendation, a summary of three
>> proposals, and ends with a longer recommendation.
>> We are here, and it's contentious:
>>     var video = document.getElementById("video");
>>     video.generateKeyRequest("org.w3.clearkey", null);
>> Let's go here:
>>     var video = document.getElementById("video");
>>   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.

These guys are looking to do something through video instead of object; 
getContext would give them a point to bind to.

It provides an extension mechanisms to media, so that DRM providers can 
implement it outside of HTML, just as webgl has done with Canvas.
Khronos has done just fine having webgl work some places, and not others.

There are mechanisms where devices decode data outside of the OS, and 
even the OS is never granted full access to the data.
Signed messages are passed around. So if the UA, the OS are hacked or 
the network connection is tapped, the message is still secure.
That's desirable for the video element, and having a getContext method 
to access such security makes some sense.

Having video.getContext('experimental-inkml') might make sense; given 
the many sports shows that use ink on video.
It could work very well with optimized streams of the khan academy 

Those are two use cases that are not about US DRM; they're to provide 
foundation for adding a getContext method for Image and Media extensibility.

Netflix capitulation to the content protection mechanisms passed down by 
the content distribution deals is a sorry thing, but that's their business.
I know you and Hixie and Henri see their position as weak and the 
promotion of DRM as unethical. That's OK.

I realize that we consensus is a good thing when adding methods. I'm 
trying to build it brick by brick.

Now sure, if you believe I'm building a slaughterhouse here, then you're 
not going to want to allow me to place even the first brick.
At present, we're just looking at the goals of one group; we can call 
them corrupt, but at some point, there is progress to be made.

If you have some hope that getContext can be a multi-tenant building, 
then maybe we can build something useful.


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

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:21 UTC