This is <i>awesome</i> news. No patent encumbrance means Firefox will support it. Terrific performance means the rest of us will actually use it. Google backing the technology means Youtube, with their unfathomably large proportion of the world's video content, will support it.<p>Sweet.
Kudos to Google for being smart enough to realize that an open web is a win for them in the long run and for having the guts to compete on the strength of their products and not on platform/api lock-in. Obviously it's still an uphill battle to get this adopted across the board but they're setting the right example here.
This is basically a done deal, fwiw. Other folks who I've talked to in a nda-ish sort of manner have been expecting to not support OGG long term, and instead support VP8 as the "open standard." It's an open secret in industry circles, and this I think confirms it. Can't wait till next week.
Are there any chips out there that do hardware decoding of VP8? That's a critical path item to get Apple on board - they've learned from Nintendo; battery life is too precious to sacrifice for a mere codec.
Ok I am going to say it: I think this finally secures a big big future for Chrome.<p>It will now be the only browser to support all three of the main codecs - and Google will control one of the two open source / royalty free ones (indeed it's arguable that status may be more secure that Ogg Theora because, simply, Google are likely to aggressively defend any submarine attacks).<p>All told - great news.
Is it possible for existing H.264 hardware decoder chips to be used to (even partially) help decode VP8? Or will we see a new generation of chips that does H.264 and VP8?
This is pure speculation but maybe Google uses VP8 in order to negiotiate a better licensing fee once h.264 isn't free anymore. MPEG-LA would think twice about loosing Youtube as a customer. This would go against Google's "Don't be evil" but getting the world to accept yet another video codec will be an uphill struggle, even for Google.
Surely making the codec open source isn't in itself that interesting, considering that x264 and FFmpeg form a high quality, open source codec for H.264? It's not the code, but the spec that matters in spreading adoption of VP8. (Of course, publishing the code would create a de facto spec).<p>More interesting still is the patent issue. VP8 is still effectively irrelevant unless Google announces they've performed a patent search and found VP8 to have no known patents covering its methods (or at least any that might incur licensing fees). After all, it was the patent issue with H.264 that bothered Mozilla.
As the article points out, the big wildcard is Microsoft. I don't see what logical reason Microsoft has for skipping VP8 other than the anti-Google animosity, but that has led to illogical decisions on their part before.
This may not solve the problem, as companies like Apple, Microsoft, Adobe, Nokia, etc need to get on board as well. They are likely to continue the same arguments they raised against Theora; most importantly that VP8 is still vulnerable to patent extortion despite being independently developed. It's probably too much to ask for Google to provide indemnification from patent lawsuits, but hopefully they've at least done some work to help assuage these concerns.
How does this relate to Google's funding of ogg/theora for mobile codecs?
<a href="http://google-opensource.blogspot.com/2010/04/interesting-times-for-video-on-web.html" rel="nofollow">http://google-opensource.blogspot.com/2010/04/interesting-ti...</a><p>Given that theora is based on On2's VP3, could there be enough similarity in the codecs that the theora DSP code is useful for quickly getting VP8 going?
Is anyone besides me worried that Steve Jobs is going to say "they tried to kill the iphone, so we will never adopt their evil standards!"? Is the animosity between google and apple enough to stifle development?
I'm not seing any confirmation from Google for now or any other sources. This is probably going to happen anyway, but for now I won't take it as a sure thing.