[whatwg] More YouTube response

Ok - sounds like pretty much unanimous objection to the idea of DRM plugins
being instantiated via <video> tag.  I'll still be pushing on the DRM plugin
providers to implement an interface that mimics the <video> tag - my primary
goal is to be able to have a single player implementation independent of
whether or not DRM is involved.  It's not the end of the world if one uses
<video> and the other uses <embed>.

-John

On Mon, Jul 5, 2010 at 8:45 AM, Nils Dagsson Moskopp <
nils-dagsson-moskopp at dieweltistgarnichtso.net> wrote:

> John Harding <jharding at google.com> schrieb am Thu, 1 Jul 2010 15:59:37
> -0700:
>
> > 1. Standard Video Format
> > [?]
> > On the current path, a content provider knows
> > that by offering H.264 and WebM, they can reach all HTML5-capable
> > browsers.  This honestly is a reasonable state for YouTube right now
> > - we use H.264 in cases outside the <video> tag as well, but it would
> > be nice to converge on a single baseline format at some point in the
> > future.
>
> Practically, I think the ball is / was in Apple's court to decide this.
> While to this day other browser makers have decided to ship two (!)
> royalty-free video formats (Theora and VP8), Apple is the single H.264
> holdout, and they have a tight itegration to their hardware as well.
>
> Sadly, I do not have hope for any consolidation regarding video
> formats. And while Youtube may be fine with having to provide only two
> formats instead of a dozen, for the common smaller webmaster this is a
> significant task, as transcoding resources are limited.
>
> Recently, I have been discussing <video> implementation with the
> administrator of an imageboard. It was ultimately decided to not add
> this feature, precisely because of the multitude of video formats of
> which none can be played in every modern browser. It's a shame.
>
> > [?]
>
> > 3. Content Protection
> > [?]
> > The basic requirements
> > around content protection that we get from content owners basically
> > consist of encrypting the content and limiting the decryption to a
> > "verified" and authorized client - the realm of traditional DRM.
>
> This can not possibly work if you have an open standard, which by
> design has to be implementable by everyone who cares, which includes a
> wide range of free and proprietary software vendors.
>
> > Rather than ask browsers to get into the DRM business, what I think
> > would work best is having a means for 3rd party DRM providers to
> > supply browser plug-ins which implement the <video> tag for protected
> > content - not all that different than selecting a pluggable codec.
>
> To define a feature like that would hurt an otherwise open standard and
> help to balkanize the browser market even more. If you really want to
> do this, why not just use flash / java / whatever can deliver using
> already available proprietary means ?
>
> > [?]
>
>
> Greetings,
> --
> Nils Dagsson Moskopp // erlehmann
> <http://dieweltistgarnichtso.net>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100707/4c37c90f/attachment-0001.htm>

Received on Wednesday, 7 July 2010 14:50:44 UTC