Re: Oppose DRM ! Re: CfC: to publish Encrypted Media Extensions specification as a First Public Working Draft (FPWD)

On Tue, Jan 29, 2013 at 4:55 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Wed, Jan 30, 2013 at 12:29 PM, Glenn Adams <glenn@skynav.com> wrote:
>
>> Have the authors of HTMLVideoElement even tried to document any of the
>> black boxes known as video decoders? No they haven't. They didn't for a
>> good reason.
>
>
> We didn't need to, because the media formats people were using were
> already well documented/standardized. For media formats, that information
> is all you need for an iinteroperable implementation; there is no need to
> integrate a particular piece of code or obtain secret keys. None of this is
> currently true for CDMs.
>
> When are folks going to stop standing on this red herring about plug-ins?
>> There are dozens of black box APIs in use in the OWP specifications and
>> more are being introduced every day it seems. For example, one of the
>> opponents of EME in this this thread whom you quote (roc), specifies the
>> use of a media stream processor in [1], obtained via
>> MediaStream.createProcessor(), which is no different than EME in terms of
>> its implied need of either a plug-in or an extensible architectural
>> component.
>
>
> a) That proposal never even made it to first draft. Your link just points
> to a snapshot of work-in-progress.
>

Could you clarify this? It looks like the proposal ended up as a published
Working Group NOTE [1].

[1] http://www.w3.org/TR/streamproc/


> b) My intent was that all built-in stream processors would be properly
> specified.
> c) Using a string there was a mistake that I would have rectified if the
> proposal had progressed. I made my position on this quite clear a while
> ago: http://robert.ocallahan.org/2012/05/canvas-getcontext-mistake.html,
> especially the last paragraph.
>