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>.<div>

<br></div><div>-John<br><div><div><br><div class="gmail_quote">On Mon, Jul 5, 2010 at 8:45 AM, Nils Dagsson Moskopp <span dir="ltr"><<a href="mailto:nils-dagsson-moskopp@dieweltistgarnichtso.net">nils-dagsson-moskopp@dieweltistgarnichtso.net</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">John Harding <<a href="mailto:jharding@google.com">jharding@google.com</a>> schrieb am Thu, 1 Jul 2010 15:59:37<br>


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