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

I think Charles makes a good point here. The technology industry is rife
with outdated standards that get dragged along even after their relevance
is past.

I wonder if there is a path between requiring a baseline and throwing up
our hands.

Perhaps we specify a "suggested" baseline and make it very easy and
attractive for implementers to adopt. When a better "baseline" candidate
comes along, we specify that as a new suggested baseline. The market
manages the transition and the baseline spec is never canonized into main
(and presumed enduring) specification.

There are of course many questions and potential problems with this
approach, but I thought I'd throw something out there.

-Clarke

On 3/1/12 12:11 PM, "Charles Pritchard" <chuck@jumis.com> wrote:

>On 3/1/2012 10:37 AM, Tab Atkins Jr. wrote:
>> On Thu, Mar 1, 2012 at 10:06 AM, Mark Watson<watsonm@netflix.com>
>>wrote:
>>> To clarify:
>>> - a browser can have multiple CDMs for different keysystems
>>> - what we propose to standardize is the discovery, selection and
>>>interaction
>>> with CDMs, not the CDMs themselves (not unlike the current situation
>>>with
>>> codecs).
>> One point that has been made multiple times is that the current
>> situation with codecs is *horrible*.  It is not a good solution that
>> we should attempt to emulate; it's a filthy, painful hack that was the
>> best we could do if we wanted a<video>  element, given the standoff
>> between browsers on which to support.  If there was a way to go back
>> in time and convince everyone to use a single codec, that would be
>> *great*.
>
>The feedback I've received on this issue is that vendors do not want a
>baseline codec to be part of specifications. Canvas+PNG is a fluke that
>was reluctantly picked up, for the sake of compatibility.
>
>I surveyed vendors recently to see if we could have a baseline for
>lossless audio recording. Some of the reasoning I heard back was that we
>should not hook ourselves into a standard media format now which would
>be obsolete in the near future. I don't see a way to get around
>ideals/principles. It's not a standoff over one format or development.
>It's about not defining (or over-specifying) these parts of
>implementation.
>
>Now, I'd hoped with lossless audio, we could have something that's
>simple, good enough, and non-controversial, as it'd be lossless and
>royalty free. But, that didn't float. And because that didn't float, I
>don't expect other items, such as video codecs, to float. We can get
>upset over that position, but it's not going to produce anything of
>substance. The parties involved have opposing views.
>
>Let's keep in mind, <audio> playback/codec issues can be worked around:
>https://github.com/JensNockert/aurora.js
>http://codecs.ofmlabs.org/
>"it is possible to play MP3 and Apple Lossless even in browsers without
>native support"
>
><video> requires a lot of processing power; hardware decoding is much
>preferred:
>https://github.com/mbebenita/Broadway
>http://libwebpjs.hohenlimburg.org/vp8/webm-javascript-decoder/
>
>Having a baseline in video means hardware support, and that's going to
>have to happen through market forces, not here.
>
>Mark's position, that the CDM is outside of spec, seems reasonable given
>the existing scene.
>
>I do want to see an example implementation sometime, just as the WebRTC
>folk did.
>
>And as for the market, we'll see where Google takes things, both with
>HTML5 Video over YouTube, and with WebM. They are setting that stage.
>
>-Charles
>

Received on Thursday, 1 March 2012 19:50:47 UTC