- From: Charles Pritchard <chuck@jumis.com>
- Date: Thu, 23 Feb 2012 17:08:56 -0800
- 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