Yes, I broke my own rules and used a "breaking" modifier for this story (let me have my fun for once). Here we have it, as the rumour mill suggested, Google has released the On2 VP8 video codec as open source (royalty free, BSD-style), while also launching the WebM container format which combines a VP8 video stream with Vorbis audio. Support for WebM has been enabled on YouTube's HTML5 beta, and you can download patches against ffmpeg as well as DirectShow filters for Windows (Gstreamer plugins are labelled as "coming soon"). Mac users are out of luck for now; no QuickTime plugins have been announced yet. Update: The WebM blog is now open - and the list of partners is pretty decent already. It includes ARM, NVIDIA, AMD, Qualcomm, and many others. Update II: VP8 will be baked into Flash. Update III: The Opera labs version with WebM support has been released too, for Linux, Mac, and Windows.

Dang! That is my one complaint with android. Its improving so fast, I'm having a hard time justifying buying a new device that doesn't have the new cool features it will have in six months. I think I'll just buy a relatively popular froyo device and hope it gets updated to gingerbread soon after its release. If I could only upgrade the os myself, this would be less of a concern.

And is this DSP dictated by Android to be a specific chip and/or does Android as provided to device manufacturers come with the DSP specific code they need for their hardware? If not the point still remains as these chips will need updating to support the format. No chip update, no acceleration.

They can, but this mac user won't. Never liked FF under linux, don't like it on the mac either and I don't see any benefit of Chrome over Safari. I'm sure with the codec being open source it will be bundled up into Perian or something and so Safari will gain support that way.

Probably this is one of the few things that can benefit from a BSD style license. If many company adopt it and it finds a way in many products, there will be enough interest to improve it, even if nobody is required to publish his modifications.

One negative aspect is that it could lead to closed source forks which are incompatible between one another.

Probably this is one of the few things that can benefit from a BSD style license. If many company adopt it and it finds a way in many products, there will be enough interest to improve it, even if nobody is required to publish his modifications.

BSD-style licenses are good for infrastructure code that sits below applications (codecs, network stacks, protocols, dictionaries, libraries, etc). Things that you want multiple groups to pick up, and to include in their products, to improve interoperability and compatibility. Does it really matter if MS or Apple or Foo Inc takes the code, sticks it in Widget Y, and then sells it? No. It's better they took this code then wrote their own from scratch causes all kinds of incompatilities.

Very nicely put. I would also add open source implementations of proprietary formats under the GPL umbrella (like samba). That serves to unify the effort to achieve compatibility with the proprietary format.

BSD-style licenses are good for infrastructure code that sits below applications (codecs, network stacks, protocols, dictionaries, libraries, etc). Things that you want multiple groups to pick up, and to include in their products, to improve interoperability and compatibility. Does it really matter if MS or Apple or Foo Inc takes the code, sticks it in Widget Y, and then sells it? No. It's better they took this code then wrote their own from scratch causes all kinds of incompatilities.

" One negative aspect is that it could lead to closed source forks which are incompatible between one another.

If there are any incompatible forks they will likely be open source. "

Hardly. The whole goal of open source is to satisfy a need of developers and users ... and therefore compatibility would be a primary aim. The whole goal of making an incompatible variant is to lock people in to your product only.

If there are going to be any incompatible forks they will likely be closed source.

BSD is a much better fit for a codec since it can be used in proprietary browsers and video players without any issues.

Wow. We actually agree on something for once.

The license terms for any piece of software are set by the authors/owners of that software. Google's purpose is therefore what counts, and what should determine the license they choose, and Googles purpose here is clearly best served by a BSD-style license.

"Hardly. The whole goal of open source is to satisfy a need of developers and users ... and therefore compatibility would be a primary aim.

Why isn't compatibility a primary aim of distro creators? Is there some charter of open source that they haven't read? Perhaps Linux audio developers need to look at that charter as well. "

Exqueeese me? WTF? Linux distros are all compatible ... they all use the same set of source code after all. They are simply different selctions of which exact applications are selected and tested for that distribution, and which package management system is used.

You will have no trouble at all taking an aduio file prepared using an Ubuntu system and using it on a Fedora box. They are completely and utterly interoperable.

" The whole goal of making an incompatible variant is to lock people in to your product only.

Incompatibility is more often caused by apathy. Forks occur for a variety of reasons and developers have limited resources so compatibility is not always a priority. "

Whatever the reasons for it, it is not a problem for open source systems. It is very much a problem constrained to closed source.

You really, really, really don't understand FOSS at all, do you? It may help you to finally figure out what open source is all about, what drives it and what motivates it if you understand its buisness model. FOSS is most like a Consumer's Cooperative. http://en.wikipedia.org/wiki/Consumers'_cooperative
Now, if we are all co-operating, incompatibility doesn't help us much at all, does it? Competing applications? yes; variety and choice? yes; incompatibility? - no.

" If there are going to be any incompatible forks they will likely be closed source.

No I think in this case a people's programmer is more likely to fork than a company. Building a commercial codec with VP8 as a base is a very sketchy business proposition. "

Hardly. Google have announced 40 partners for WebM and today is only its launch date!

Linux distros are all compatible ... they all use the same set of source code after all.

They take various parts from the same source pile with no goal of compatibility between them. They don't have application compatibility which is what matters when it comes to operating systems. They clash on all sorts of petty issues like where program files should go and which package format should be used.

You will have no trouble at all taking an aduio file prepared using an Ubuntu system and using it on a Fedora box. They are completely and utterly interoperable.

I can take an mp3 prepared in a Mac and use it Windows but that doesn't make the two systems completely and utterly interoperable.

If you create an audio application for one distro you can have problems running it in another due to incompatible audio stacks.

You really, really, really don't understand FOSS at all, do you?

You're the one that has a skewed understanding. Ever heard the term "to scratch an itch"? It's the rationale behind a lot of open source. It doesn't exist to serve users or produce compatible code for a unicorn collective. It solely exists to meet the needs of the developer. I don't have a problem with that but I do grow tired of naive FOSS advocates that think open source is one big people's movement.

Hardly. Google have announced 40 partners for WebM and today is only its launch date!

Those companies do not plan on building their own proprietary codecs from the VP8 base. Their plans are in fact irrelevant to the point which is that forking VP8 into a proprietary product is a sketchy proposition due to patents and the entrenched position of H.264. Utilizing VP8 as part of a video delivery service is an entirely different matter.

"Linux distros are all compatible ... they all use the same set of source code after all.

They take various parts from the same source pile with no goal of compatibility between them. They don't have application compatibility which is what matters when it comes to operating systems. "

No it doesn't. Is Windows 7 64-bit binary-compatible with Windows 7 32-bit? No, not for everything ... e.g. drivers. What about Linux drivers? Linux can, and does, use essentially the same source code for a quite large number of platforms.

What matters is source code compatibility, not binary package compatibility. You are heavily infested with Windows-proprietary-think if you imagine that binary compatibility of application packages matters at all.

They clash on all sorts of petty issues like where program files should go and which package format should be used.

So? This is what distributions are for.

" You will have no trouble at all taking an aduio file prepared using an Ubuntu system and using it on a Fedora box. They are completely and utterly interoperable.

I can take an mp3 prepared in a Mac and use it Windows but that doesn't make the two systems completely and utterly interoperable. "

Yes, it does. MP3 files, wordprocessing documents, text files, all kinds of files and formats ... completely interchangeable and interoperable between different Linux systems, even ones working on completely different CPU architectures. This is the very definition of interoperability.

If you create an audio application for one distro you can have problems running it in another due to incompatible audio stacks.

Recompile it with different switches depending on the audio layer you are targetting and the CPU architecture. Source code compatibility. Linux has no problem at all running VLC on a dual-core AMD X86_64 desktop and the exact same application on a Qualcomm ARM smartbook (ARM), which are two platforms with completely different audio stacks and system architectures. Source code compatibility ... but not binary compatibility.

This is what different distributions are for.

" You really, really, really don't understand FOSS at all, do you?

You're the one that has a skewed understanding. Ever heard the term "to scratch an itch"? It's the rationale behind a lot of open source. It doesn't exist to serve users or produce compatible code for a unicorn collective. It solely exists to meet the needs of the developer. "

Nope. The original developer hits a brick wall, and so releases it as open source. Thousands of others chip in, and it evolves to meet the needs of everybody in the collaboration. Meritocracy. The original "itch" has long since become irrelevant.

I don't have a problem with that but I do grow tired of naive FOSS advocates that think open source is one big people's movement.

Why? What's it to you? Why would you have a problem, either way, if it was or it wasn't?

" Hardly. Google have announced 40 partners for WebM and today is only its launch date!

Those companies do not plan on building their own proprietary codecs from the VP8 base. Their plans are in fact irrelevant to the point which is that forking VP8 into a proprietary product is a sketchy proposition due to patents and the entrenched position of H.264. Utilizing VP8 as part of a video delivery service is an entirely different matter. "

There is more to life than just people who write code and make devices. There is a whole digital web video enterprise out there with a stake in this of some kind or another, and for the vast, vast majority of the people on the planet, Webm represents a marvellous opportunity to increase profit or reduce costs (or maybe both, the former via the latter).

Why on earth would you be keen to see that upset? Why is it that you apparently so dearly want to kick the vast majority of people in the teeth all the time?

Subject to the terms and conditions of the above License, Google hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer this implementation of VP8, where such license applies only to those patent claims, both currently owned by Google and acquired in the future, licensable by Google that are necessarily infringed by this implementation of VP8. If You or your agent or exclusive licensee institute or order or agree to the institution of patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that this implementation of VP8 or any code incorporated within this implementation of VP8 constitutes direct or contributory patent infringement, or inducement of patent infringement, then any rights granted to You under this License for this implementation of VP8 shall terminate as of the date such litigation is filed.

VP8, as a spec, should be a bit better than H.264 Baseline Profile and VC-1. It’s not even close to competitive with H.264 Main or High Profile. If Google is willing to revise the spec, this can probably be improved.

VP8, as an encoder, is somewhere between Xvid and Microsoft’s VC-1 in terms of visual quality. This can definitely be improved a lot, but not via conventional means.

VP8, as a decoder, decodes even slower than ffmpeg’s H.264. This probably can’t be improved that much.

With regard to patents, VP8 copies way too much from H.264 for anyone sane to be comfortable with it, no matter whose word is behind the claim of being patent-free.

VP8 is definitely better compression-wise than Theora and Dirac, so if its claim to being patent-free does stand up, it’s an upgrade with regard to patent-free video formats.

VP8 is not ready for prime-time; the spec is a pile of copy-pasted C code and the encoder’s interface is lacking in features and buggy. They aren’t even ready to finalize the bitstream format, let alone switch the world over to VP8.

Heh, I would say definately biased. The x264 devs are currently contacting all their contributors in order to change to a dual licence so that they can charge money for proprietary versions of x264. In recent months the x264 dev's have systematically made posts/articles where they attack theora. I think this blog post will be followed by others from the rest of the x264 devs.

The x264 devs are currently contacting all their contributors in order to change to a dual licence so that they can charge money for proprietary versions of x264.

Interesting. If I was a paranoid nut, I would speculate that doubt has been cast over whether the open source version of x264 is legal at all, so they need to have a proprietary version that has been paid for to the MPEG-LA racket.

"The x264 devs are currently contacting all their contributors in order to change to a dual licence so that they can charge money for proprietary versions of x264. "

Good luck with that. I think some of those devs work at Red Hat. I hope RH manageress to interfere and say firm NO to dual-licensing. That will make x.264 bozos rewrite parts owned by RH and make otherwise crappy decoder even more crappy and they will also lose lots of time and momentum it the process.

If google does not fight back the same thing will happen with VP8. They can use the On2 video patents against the MPEG-LA members. On2 has been in this business for a very long time and probably has many patents that cover H264 functionality.

Yes very premature. Plenty of devices have hardware support for h264. How many have VP8 support?

They most likely have a generic DSP which can be re-programmed. Those are available in large quantities and aren't very costly. Whereas developing a DSP which can ONLY support H.264, both in hardware and in software, would cost quite a lot and benefit nothing.

As such, it is quite possible it would be perfectly possible to add support for VP8 to existing hardware. The problem then again is that manufacturers don't want to introduce new features in old devices; they want you to buy a new one. So, don't expect your old devices to get support for VP8 because of no hardware support; expect it not to get support because of manufacturers being greedy.

As such, it is quite possible it would be perfectly possible to add support for VP8 to existing hardware. The problem then again is that manufacturers don't want to introduce new features in old devices; they want you to buy a new one. So, don't expect your old devices to get support for VP8 because of no hardware support; expect it not to get support because of manufacturers being greedy.

Exactly, support will be confined to new hardware, or a small selection of older hardware. Add the issue of people not updating their firmware (firmware? what's that?) and you end up a distinct lack of current devices supporting the format.

Exactly, support will be confined to new hardware, or a small selection of older hardware. Add the issue of people not updating their firmware (firmware? what's that?) and you end up a distinct lack of current devices supporting the format.

Hardware support is mostly needed in mobile devices where you need to save battery life. Such devices do not usually have a lifespan of more than two to three years, people drop them, loose them, or the fast development of mobile OSes and applications that will make them obsolete due to e.g. higher hardware requirements in general.

The market for mobile devices is expanding, and new devices alone will be enough to make it worth while to switch to the new format. As an example, there are currently sold 65000 Android devices each day. With that growth rate it will not be a problem if only new devices are supported.

I'm pretty certain Google is doing this because it makes sense from a business perspective first and foremost

Of course, that's only natural. Companies do not mind paying license fees but no-one likes to be subject to extortion practices like the ones of MPEG-LA. That's why you see so many other companies supporting WebM. MPEG-LA did this to themselves, really.

..will flash support it? Google and adobe seem to be best friends these days, mr, google, can you talk to your friends at adobe and it happen?

Native support for VP8+theora+vorbis on flash will mean most contents will be able to be encoded on one format and can be played on most computers and devices. This is, if apple decides to support them in their hardware.

According to the in-depth code analysis here: ( http://x264dev.multimedia.cx/?p=377 ) it has a big red target painted all over it. I have very serious doubts the MPEG-LA won't sic their lawyers on this.

Seriously. Let's see MPEG-LA put up and bring suit since "all codecs are patent protected". Posting this by Google -- on YOUTUBE, they have put up or shut up. Let them cry FUD all they want. If they have a case, bring it. Otherwise STFU.

I wonder where are the H.264 backers now? Have any of you guys seen that ARM is one of the hardware partners and thus that any concern regarding the lack of hardware acceleration will most likely be moot in the foreseeable future?

I wonder where are the H.264 backers now? Have any of you guys seen that ARM is one of the hardware partners and thus that any concern regarding the lack of hardware acceleration will most likely be moot in the foreseeable future?

Damn, sometimes it is really hard to dislike Google!

Indeed, I noticed they've garnered an impressive selection of names and ARM being the Big Name(TM) in mobile devices and Google getting them along clearly reads like Google going for the kill.

VP8 becoming open-source and having so much support all the way from the beginning promises good times for alternative browsers, OSes, and in general for content producers and content viewers!

....as well as VP8 video when the user has installed a VP8 codec on Windows

It won't be built into the browser, it'll be simply a DirectShow/Media Foundation plugin. They're in the same situation as Safari since Apple uses QuickTime and Google has planned to deliver a QuickTime plugin which will bring VP8 support to Safari in the same way VP8 will be bought to the Internet Explorer world.

Now, we just have to see if this stands up against the patent trolls. Results-wise, it looks miles better than Theora and manages to match Xvid and VC-1, but the fact that as skilled a codec coder as the head of the x264 project say that things look rather close to H.264 in places worry me about what the MPEG-LA might do.

As pointed out by someone on Engadget, if VP8 development actually started with VP7, then VP8 predates h264 development and can claim prior art on those similarities.

Of course, if VP8 was an ongoing project, that'll be harder to prove. And, even if they CAN claim prior art, that's probably not going to stop lawyers from suing and stalling or even just threatening everyone involved.

I was browsing through the Slashdot comments section and it seems people are really terribly scared of VP8 still being patent-encumbered and they are hailing H.264 as the safe bet.

There's just a whole lot of things they're not taking into account: Google bought On2, including all the patents they had, and VP2 predating H.264 means they most likely have stuff they can throw at H.264 if they wish. Also, atleast Sorenson and Qualcomm have been in video encoding business for so god damn long that they too are definitely bound to have something they could throw in. MPEG-LA can't really start suing anyone for VP8 if they don't want to get sued for H.264 and then would all hell be loose.

There is no way H.264 wouldn't also infringe on atleast some patents, there's just WAY too many patents altogether to be aware of them all. As such I don't see it any more safe choice than VP8.

Now, there's also lots of comments about speed of VP8 and the encoder. Well, they forget VP8 has been closed until now and that there's literally thousands, if not even hundreds of thousands, people out there who are devout proponents of all things open and who happen to posses excellent coding skills; the flood gates are open and you can bet your ass there's changes a-coming. Even if the decoder is slow now it is always possible to optimize it, and so is the encoder. They can even retain full compatibility with the VP8 bitstream while still enhancing the quality of the encoded picture.

It just will take some time. It's a wrong approach to expect everything to be all shiny and perfect from the get-go.

I was browsing through the Slashdot comments section and it seems people are really terribly scared of VP8 still being patent-encumbered and they are hailing H.264 as the safe bet.

Well there is a legitimate concern when it looks like part of VP8 was directly copied from H.264:

VP8’s intra prediction is basically ripped off wholesale from H.264: the “subblock” prediction modes are almost exactly identical (they even have the same names!) to H.264’s i4×4 mode, and the whole block prediction mode is basically identical to i16×16. Chroma prediction modes are practically identical as well.

Don't trust those links to x264 devs. Those guys are in the process of starting to charge money for x264, and as such, VP8 is a competitor fo theirs. It's like believing Microsoft without a doubt when they say Windows is better than Mac OS X.

Also, iirc he wanted VP8 to be opened so that he could study it due to professional curiosity, not because he wanted it to be the web standard for video (which he has made no secret that he thinks h.264 is best for).

x264 is most likely the best h.264 implementation out there and I see nothing wrong with them making money of of their hard work on it. I do question their objectivity when viewing competing codecs since they have actually written the excellent x264 which is 'their baby' so to speak, and also because as aforementioned they are hoping to make money from companies who wants to incorporate it into proprietary products (and thus might want to forego the gpl licence).

h.264 isn't going anywhere, bluray discs won't change to vp8, streaming movie sites will likely stick with h.264. But now we have a free open source codec which can be incorporated into every open source/proprietary product, can be used on every website and won't cost a dime. If it's not as good as h.264 then so be it, being able to watch videos on practically any site on practically any platform I choose (Haiku ftw! ) is a future I really look forward to.

Don't trust those links to x264 devs. Those guys are in the process of starting to charge money for x264, and as such, VP8 is a competitor fo theirs. It's like believing Microsoft without a doubt when they say Windows is better than Mac OS X. "

Yes, instead trust bunch of amateurs in some silly news site to tell you truth. Atleast those guys know what they do. Intresting to see how Google will dodge patent problems, poor spec, poor source code. Like they said" it took 7 years to fix Theora" and I agree.

excerpts: Jason's comparison isn't unfair but you need to understand it for what
it is— he's comparing a very raw, hardly out of development, set of
tools to his own project— which is the most sophisticated and mature
video encoder in existence. x264 contains a multitude of pure encoder
side techniques which can substantially improve quality and which
could be equally applied to VP8. For an example of the kinds of pure
encoder side improvements available, take a look at the most recent
improvements to Theora:

Even given that, VP8's performance compared to _baseline profile_
H.264 is good. Jason describes it as "relatively close to x264’s
Baseline Profile". Baseline profile H.264 is all you can use on the
if you actually want to be compatible with a great many devices,
including the iphone.

On the patent part— Simply being similar to something doesn't imply
patent infringement, Jason is talking out of his rear on that point.
He has no particular expertise with patents, and even fairly little
knowledge of the specific H.264 patents as his project ignores them
entirely. Codec patents are, in general, excruciatingly specific — it
makes passing the examination much easier and doesn't at all reduce
the patent's ability to cover the intended format because the format
mandates the exact behaviour. This usually makes them easy to avoid.
It's easy to say that VP8 has increased patent exposure compared to
Theora simply by virtue of its extreme newness (while Theora is old
enough to itself be prior art against most of the H.264 pool), but
I'd expect any problems to be in areas _unlike_ H.264 because the
similar areas would have received the most intense scrutiny. ... and
in any case, Google is putting their billion dollar butt on the line—
litigation involving inducement to infringe on top of their own
violation could be enormous in the extreme.

So as you see there are other views on the subject than that of the x264 dev. I'm not saying that this is "the truth" or that Greg Maxwell is more objective than the x264 dev, but simply that to trust one single source, especially one with monetary motivations as being objective is pretty stupid. We'll see in the coming months exactly what vp8 can and cannot do, and if it does infringe on h.264 patents that will certainly also come to light.

Right, but how can you be so sure that it is not h.264 that's the one that has copied? Also, almost identical != identical and there are only so many ways to do some things. The fact that the names are the same really means nothing.
We should perhaps also keep in mind that the x264 devs might not be entirely impartial.

MPEG LA may not even care since publishers like Hulu will continue to use Flash.

You realize that flash video is a container, right? And from the summary blurb of this newspost Adobe is incorporating VP8 into flash. So movie sites using flash can use V8 just as easy as they are using h.264. That's not saying they will, but wether they do or not won't depend on their use of flash as video container.

You realize that flash video is a container, right? And from the summary blurb of this newspost Adobe is incorporating VP8 into flash. So movie sites using flash can use V8 just as easy as they are using h.264. That's not saying they will, but wether they do or not won't depend on their use of flash as video container.

Are you assuming that they will offer naked VP8 video along with Flash? Movie and TV producers don't like HTML5 because it doesn't offer content protection.

Anyways if VP8 becomes just another codec for publishers to choose from then they will likely go with H.264. But even a company like Hulu switched to Flash + VP8 that really doesn't make the web any different than it was 5 years ago. Everyone will still install Flash for that one site they like and web designers will continue to target Flash because everyone has it installed.

Are you assuming that they will offer naked VP8 video along with Flash? Movie and TV producers don't like HTML5 because it doesn't offer content protection.

First off, you said that "publishers will continue to use flash" as if flash could only stream h.264, I pointed out that it can stream v8 just as well. Secondly what does content protection have to do with h.264 or vp8 in this case? Are you saying that flash won't be able to serve encrypted vp8 video same as it can serve encrypted h.264 video, and if so why?

"You realize that flash video is a container, right? And from the summary blurb of this newspost Adobe is incorporating VP8 into flash. So movie sites using flash can use V8 just as easy as they are using h.264. That's not saying they will, but wether they do or not won't depend on their use of flash as video container.

Are you assuming that they will offer naked VP8 video along with Flash? Movie and TV producers don't like HTML5 because it doesn't offer content protection. "

Adobe Flash is one of the partners in the WebM thing. I'd assume that Adobe's model is to use a Flash wrapper with VP8 and include DRM. This would suit "Movie and TV producers" and at the same time reduce Adobe's costs (because right now I'm assuming they pay MPEG LA royalties). Flash/VP8 would mean no royalties for Adobe to pay. Better for Adobe, no skin of the nose of "Movie and TV producers".

Fortunately, "Movie and TV producers" are a tiny, tiny part of the web video scene. For the vast majority of web video use cases (e.g. YouTube, Dailymotion, Wikipedia, Wikimedia, even Vimeo, et al), HTML5/VP8 (sans DRM) is a far better option. No open source browser will ship with DRM embedded.

Anyways if VP8 becomes just another codec for publishers to choose from then they will likely go with H.264.

Why? Extra costs, no gain (compared with WebM), for most use cases.

But even a company like Hulu switched to Flash + VP8 that really doesn't make the web any different than it was 5 years ago.

It does for Hulu and Adobe (cheaper). It does for MPEG LA members (they don't get to rip people like Hulu and Adobe off). If Hulu and Adobe have lower costs, some of that savings could be passed on the everyone else (assuming a price-sensitive competitive supply and demand free enterprise market).

Everyone will still install Flash for that one site they like

Not the point. See the bit about cost savings above.

and web designers will continue to target Flash because everyone has it installed.

It would appear that it won't be long before everyone has HTML5/WebM installed also.

It does for Hulu and Adobe (cheaper). It does for MPEG LA members (they don't get to rip people like Hulu and Adobe off). If Hulu and Adobe have lower costs, some of that savings could be passed on the everyone else (assuming a price-sensitive competitive supply and demand free enterprise market).

That's saving some companies money, not changing the web. I thought half the point of HTML5 was to get rid of plug-ins like Flash. Sure it is good that companies will have a bargaining chip when dealing with MPEG LA but....are we supposed to be excited about this?

It would appear that it won't be long before everyone has HTML5/WebM installed also.

No it will be a while with all the XP users who will stick with IE6/7/8 until their computer dies. I look forward to advertisers using HTML5 canvas instead of Flash for their ads but that will take a few years.

That was one of my notions as well (it's too bad you got mod'd down, probably because your comment was so terse). I can't help but feel like most of the Theora champions will now likely switch their focus to VP8. On the other hand, Theora could still be a "fallback" format if VP8 is found to be substantially patent-infringing while Theora is not. Nobody really knows how that will pan out yet. "

Theora had supporters because it used to be the ONLY royalty-free codec that was anywhere near being competitive. If VP8 is royalty-free, open, and better performing, then you can bet your life that FOSS supporters will switch to it.

FOSS is a meritocracy ... whichever has the merit wins.

Having said all that ... Google's presentation actually lists Xiph's Theora.org as software industry support.

"That was one of my notions as well (it's too bad you got mod'd down, probably because your comment was so terse). I can't help but feel like most of the Theora champions will now likely switch their focus to VP8. On the other hand, Theora could still be a "fallback" format if VP8 is found to be substantially patent-infringing while Theora is not. Nobody really knows how that will pan out yet.

Theora had supporters because it used to be the ONLY royalty-free codec that was anywhere near being competitive. If VP8 is royalty-free, open, and better performing, then you can bet your life that FOSS supporters will switch to it. FOSS is a meritocracy ... whichever has the merit wins. Having said all that ... Google's presentation actually lists Xiph's Theora.org as software industry support. http://www.engadget.com/2010/05/19/google-launches-open-webm-web-vi... Have a look at the second picture in the above link. Software group, bottom row, second icon in from the left. "

"theora.org" has diasappeared from the "Software" group, and Xiph.org now appears on its own in a new category called "Organistations".

This is probably about Xiph.org's Vorbis audio format (used within WebM) and not Theora at all.

Right, they somehow managed to grab the wrong logo. We didn't notice until the keynote was underway. I have no idea why we got moved from 'Software' to 'Foundations'. It doesn't really matter, I'm certainly not reading anything into it.

"
"theora.org" has diasappeared from the "Software" group, and Xiph.org now appears on its own in a new category called "Organistations".

This is probably about Xiph.org's Vorbis audio format (used within WebM) and not Theora at all.

Right, they somehow managed to grab the wrong logo. We didn't notice until the keynote was underway. I have no idea why we got moved from 'Software' to 'Foundations'. It doesn't really matter, I'm certainly not reading anything into it. "

On the other hand, Theora could still be a "fallback" format if VP8 is found to be substantially patent-infringing while Theora is not. Nobody really knows how that will pan out yet.

Nobody really wanted OGG/Theora, the pedants just had no other flag to wave. No one wants to pay to use h.264, but those using h.264 could see how awful OGG/Theora was when compared to h.264 for streaming etc. Now there is a different option, fingers crossed it plays out well.

"On the other hand, Theora could still be a "fallback" format if VP8 is found to be substantially patent-infringing while Theora is not. Nobody really knows how that will pan out yet.

Nobody really wanted OGG/Theora, the pedants just had no other flag to wave. No one wants to pay to use h.264, but those using h.264 could see how awful OGG/Theora was when compared to h.264 for streaming etc. Now there is a different option, fingers crossed it plays out well. "

Theora is getting better by leaps and bounds, especially for low bit-rates where up to now it has been lacking somewhat.

I realize that, but being a subset, WebM itself defines a container that is wholly compatible with Matroska, so any device, software or platform that can understand VP8, MKV, and Vorbis should already be able to play WebM without needing any specific support for it. A number of household media player devices can already play MKV and Vorbis for example.

In other words, WebM itself doesn't define anything not already defined by something else. What's new is VP8, not WebM. If you really need another name to call it, perhaps something like mkm or mkx, etc would've been more appropriate. Again just an opinion, that should not detract from the good news about VP8 in general.

Yes, we've actually known for a little while this would be happening. Google is moving quite fast after having their On2 purchase plans delayed several months. We'll have a press release up soon expressing support in drier language, though it's mostly an exercise in formality since everyone already knows our position.

Of *course* we (Xiph) support WebM. This is great news for open source, open media, and our own plans at Xiph count on WebM succeeding.

At least from a cursory look at the license FAQ, as in several parts it mentions "Google's patents" I reckon that should somebody bring up a patent litigation over a VP8-based product, that means calling straight away the 800-pound Google gorilla into court.

Just in case that same somebody thinks of a flanking attack via taiwanese/3rd-party companies...