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

Re: Encrypted Media proposal (was RE: ISSUE-179: av_param - Chairs Solicit Alternate Proposals or Counter-Proposals)

From: Charles Pritchard <chuck@jumis.com>
Date: Thu, 23 Feb 2012 17:08:56 -0800
Message-ID: <4F46E328.3080709@jumis.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: Mark Watson <watsonm@netflix.com>, Adrian Bateman <adrianba@microsoft.com>, Maciej Stachowiak <mjs@apple.com>, "HTML WG (public-html@w3.org)" <public-html@w3.org>, David Dorwin <ddorwin@google.com>
On 2/23/2012 4:42 PM, Tab Atkins Jr. wrote:
> Keeping DRM-laden video expensive and fragmented is a positive goal,
> as it makes it harder for people to achieve bad results.  This is
> similar to, say, not adding APIs to<canvas>  that make it easy to make
> text editors, because text editors in<canvas>  are a bad thing for the
> web.  There's a cheap, unified, simple solution available for
> publishers if they give up the DRM requirement (just use<video>).

Video is currently spec'd so that it's format agnostic. That's the same 
thing as DRM-laden to many people.
Netflix can go ahead and stream to a codec that only they support and 
that is completely within scope.

Further, there is no format that's guaranteed to work. Same situation 
for audio. I can't get FLAC nor ALAC to be a promised format.
This proposal is just trying to add an extra data channel to the video 
stream. It's not like they can't just pass that data long in the HTTP 
stream.
It's not like they can't just add a new protocol prefix.

Same situation is there with Canvas. Canvas can be used to implement 
other APIs, so that people can cross-compile their C/C++ programs and 
run them in the browser.
People can even implement video codecs in Canvas. And image codecs.

But if they go ahead and do that, they may still want a channel into the 
OS, so that they can pass semantic information that's present.
So they can say hey dude, here's some information in the data stream.

MS, Google and Apple want to pass some data to the OS.
At present, it seems that there are a few people who want to pass some 
data to the OS with Canvas as well.

And frankly, if it comes down to secure encryption, I'm fine passing a 
"key" to the OS so that the user can see an encrypted Canvas without it 
being exposed to the UA and OS.

Unfortunately, we get all tangled up in ideology here, and we short the 
technical issues.

In the long term, these things will work out. They'll work out because 
they are based in reality, and over time, reality wins.

In reality, hardware is connected to the OS, the OS connects to the UA, 
the UA connects to the scripting/DOM environment and the environment 
connects to the funny bone.


-Charles
Received on Friday, 24 February 2012 01:09:18 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:30 UTC