[whatwg] H.264-in-<video> vs plugin APIs

Comparing Daily Motion to Youtube is disingenuous. If yt were to
switch to theora and maintain even a semblance of the current youtube
quality it would take up most available bandwidth across the internet.
The most recent public number was just over 1 billion video streams a
day, and I've seen what we've had to do to make that happen, and it is
a staggering amount of bandwidth. Dailymotion is a fine site, but
they're just not Youtube.

Considering this 'argument'  came out of the larger issue that we're
actually shipping with Theora (also on android, too), and as we showed
at Google I/O, are sampling it on some pages at Youtube, this thread
is pretty surreal to me. I will say that the best thing that can
happen to Theora recently was firefox's support of it, though, but
even better would be substantive codec improvements or some great
advance in Dirac encoding efficiency. .

Chris

On Fri, Jun 12, 2009 at 10:02 AM, Mike Shaver<mike.shaver at gmail.com> wrote:
> Apologies for the poor threading, I wasn't subscribed when the message
> here was sent.
>
> In http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020237.html
> Chris DiBona wrote:
>> > The incredibly sucky outcome is that Chrome ships patent-encumbered
>> > "open web" features, just like Apple. That is reprehensible.
>>
>> Reprehensible? Mozilla (and all the rest) supports those same "open
>> web" features through its plugin architecture. Why don't you make a
>> stand and shut down compatibility with plugins from flash, quicktime
>> and others? How long would Firefox last in the market if it were
>> incompatible with those? Honestly.
>
> I think that "reprehensible" is excessive, and not helpful, but I
> think you're very much missing the point here.
>
> It's true that plugin support is necessary for competitiveness on the
> desktop web, because there is a lot of content out there that requires
> those plugins, for better or for worse. ?And because each plugin has
> different API (and often markup requirements), in addition to codec
> differences, migration cost is a pain. ?This is definitely a problem
> for people on iPhones and the Pre and various mobile Linux devices and
> platforms, and I gather for Android users as well.
>
> That's not the case for <video>, as far as I can tell. ?There is still
> proportionately little content on the web that uses it, and as far as
> H.264-in-<video> is concerned, basically *all* the content on the web
> is Google's! ?What legacy-content-compatibility requirement there is
> comes from services in the same company! ?Anyone else moving to
> <video> now from their legacy setups will have much more to worry
> about with respect to API changes than a simple transcoding, and the
> experiences of DailyMotion and others indicate that the transcoding
> works quite well. ?(We want it to work better, of course, which is why
> we're investing in tools and library development.)
>
> I do not like the situation on the web today, where to use all the
> content you need to have a license to Flash, and I'm saddened that
> Google is choosing to use its considerable leverage -- especially in
> the web video space, where they could be a king-maker if ever there
> was one -- to create a _future_ in which one needs an H.264 patent
> license to view much of the video content on the web. ?Firefox won't
> likely have native H.264 support, since we simply can't operate under
> those patent restrictions, so by your analogy I suppose we won't last
> long in the market -- I very much hope you're wrong about that aspect
> as well. ?And I hope that those who would follow Google's footsteps in
> joining the web browser market don't have to get such a license as
> well; that would be an unfortunate blow to the competitiveness of the
> current environment, to which Google has contributed and from which it
> has benefited.
>
> Mike
>



-- 
Open Source Programs Manager, Google Inc.
Google's Open Source program can be found at http://code.google.com
Personal Weblog: http://dibona.com

Received on Saturday, 13 June 2009 05:00:36 UTC