[whatwg] More YouTube response
jharding at google.com
Wed Jul 7 14:50:44 PDT 2010
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>.
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
> > 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 ?
> > […]
> Nils Dagsson Moskopp // erlehmann
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg