Slashdot Mirror
Google to Open Source the VP8 Codec
Several readers noted Google's reported intention to open source the VP8 codec it acquired with On2 last February — as the FSF had urged. "HTML5 has the potential to capture the online video market from Flash by providing an open standard for web video — but only if everyone can agree on a codec. So far Adobe and Microsoft support H.264 because of the video quality, while Mozilla has been backing Ogg Theora because it's open source. Now it looks like Google might be able to end the squabble by making the VP8 codec it bought from On2 Technologies open source and giving everyone what they want: high-quality encoding that also happens to be open. Sure, Chrome and Firefox will support it. But can Google get Safari and IE on board?"
According to some things i read the other day, the hardware support for h.264 is really just a programmable DSP in most cases, so they could program support for VP8 if it were being seriously considered, and that appears to be the direction of things.
The amount of money that Google paid for On2 was pocket change by Google standards. And the amount of money that On2 made every year was in the noise level by Google standards. So it never seemed likely to me that Google bought On2 with the intention of selling codecs for money.
If VP8 really is as good as On2 claimed, Google could save some pretty good money by serving up YouTube videos in VP8 format instead of H264. And even better, Google would not have to worry about the H.264 patent owners changing the rates or changing the rules. So it really would be in Google's best interest if all of the YouTube users were able to view content in VP8. But given the head start of H.264 in the market, the only possible way for Google to get everyone to use VP8 would be to release it for free.
I'm happy about this. This is just a win/win for everyone. If VP8 is decently competitive with H.264, and it is completely free, then as shutdown -p now commented, there is no longer any need to choose between good compression and free software. Everyone can have both!
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
I think that your position is flawed in two major respects:
One, codecs are, largely, infrastructure type software. They exist to do the unsexy-but-necessary job of getting content from point A to devices B, C, and D as effficiently and quietly as possible. Like networking protocols, interoperability and standardization are key, you want to be able to release a video and have it Just Work, no matter the end software or device, the same way that you can pretty much assume that any modestly sophisticated computer will speak TCP/IP correctly enough. Performance counts, since bandwidth and disk space, and battery life are all not free; but, as with operating systems, "compatible" generally beats "superior". Also of note, competition and growth do occur among infrastructure software, they just tend to be strongly shaped by the value of compatibility, and so growth and change tend to come about either through backwards-compatible evolutionary shifts, or through sudden, swift changes.
Two, there isn't much evidence supporting the thesis that FOSS destroys competition. It does tend to drive down prices(and, to be fair, it is quite possible that it destroys the role of the "proprietary-but-cheap 2nd or 3rd string player", either replacing it with free software, or with the services of "free as in freedom but not as in beer" software integrators and consultants); but, even in markets where the price is basically zero, you can usually find, at the very least, several FOSS projects duelling for users. Quite a few markets don't even go that far. If anything, by providing a solid baseline, they force proprietary vendors to compete harder.
In the specific case of video codecs, the proprietary market was already largely uncompetitive before Google showed up. Everything was either h.264(or very close variants, like VC-1), at the mercy of the giant-pool-o'-MPEG-LA-patents, or various more or less obscure legacy crap.
This is one of those things which gets me fuming more than the video tag being the most poorly thought out design issue ever on the web.
.NET in the past, but nothing with as much complexity as VP8. H.261 works with minimal CPU consumption on .NET. I've also implemented much of H.262 with little additional overhead. With the exception of the more expensive prediction methods which are definitely points where highly optimized code is beneficial, CODECs with the complexity of H.264 and VP8 should be doable.
.NET and I know it's supposedly scheduled, but cross platform vectorization frameworks are EXTREMELY complex. And to avoid them ending up with a piece of crap VM design like Java's, I'm truly hoping they'll delay the feature until they get it right.
Apple delivers video through the Quicktime architecture and Microsoft delivers video either through DirectShow or MediaFoundation. These frameworks are pluggable and CODECs can be easily installed on these platforms.
What is missing is a method of delivering the CODECs to the users. Google can make the CODEC part of Google Toolbar, Google Desktop, Google Earth, etc... there are countless ways in which Google can proliferate the CODEC to the consumer. The real issue comes in mobile devices. Delivering to the Microsoft and Apple phones. On the desktop, the CODEC issue is already taken care of.
As for supporting the VP8 CODEC on iPhone, I don't recall seeing anything that specifically bans third party CODECs on the phone itself. In fact, given that the hardware encoder in slingbox appears to be either WMV9 or VC-1 (I haven't verified it, but I read it somewhere), SlingPlayer for iPhone almost certainly is delivering a 3rd party CODEC to the device. It might simply be an issue of making a new player that triggers on VP8 media.
As for the Microsoft phone, it's both easier and harder. I have implemented low complexity CODECs in
My greatest dreams at the moment is Microsoft implementing vectorization extensions in
All said and done, VP8 can be proliferated pretty easily. At least for a company like Google who has both the means to implement it as well as the means to deploy it.
http://www.on2.com/index.php?603 I found them on on2's site. I assume those VP8s are at maximum quality, but if those are real, and this is fully open sourced, Theora AND H264 are in for a beating. I imagine that this will replace a lot of the internet... video if it's really that good.