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?"
We're all very quick to hit Google when they do something wrong. This one pretty clearly is "do no evil". Thanks Google!
Setting aside the fact that it's just rumors so far... if true, this is really great.
I was generally more supportive of H.264 in this debate for purely pragmatical purposes, but if we can have a codec that is both free, and technically capable, it's a win-win all the way.
Of course, there's still the battle to get it supported on hardware side. But then if Google truly backs it (rather than just dumping a tarball of source on the FOSS crowd), it might be dealt with much faster than how it goes for Theora now. Especially if, say, Google will push to make it supported on Android - the volume of devices is large enough that some established company can come up with a hardware decoding chip and make it profitable.
As a side note - in retrospect, sounds like it's a good thing they didn't prematurely standardize on Theora...
Open-sourcing it alone means next to nothing: there are open-source h.264 codecs. The community still can't use it without a thorough patent examination, a universal royalty-free patent license, and an indemnity guarantee.
So now instead of two incompatible codecs for HTML5 video, we will have three? Great!
The only way this will really take off is if Google starts serving up youtube in VP8 to clients that request it. I am not saying that options are bad, and its nice the Google has released this code, but HTML5 video is already hampered by competing standards and this doesn't help.
As far as HTML5 video goes, it doesn't matter so much if the technically "best" codec gets used, so long as a single format is standardised to a large degree. There are better ways of storing photos than JPG, but that's what browsers use and nobody complains. There are better ways of storing video than Theora and everybody bitches about it. I hope it gets sorted out soon one way or another - HTML5 audio is in the same boat.
sheep.horse - does not contain information on sheep or horses.
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.
its all about the encoders !
google can quite easily make reference but until there is High quality encoders then its pretty pointless
making decoder plugins for IE and mac is actually pretty easy in comparison
hardware reference designes need to be seeded also to the likes of TI and STMicroelectronics before it will even start to be useful after all where do all the camera's now do mp4 come from...
its all about the encoders !
regards
John Jones
I expect there are some programable components, but adding whole a new codec to existing hardware decoders may be asking a bit much.
However, On2 already offered VP6 video decoder hardware designs like this one: http://www.on2.com/index.php?549
And, as I understand it, one of the big factors in the VP8 codec design was correcting issues with VP7 that made it hard to implement efficiently in hardware (or parallel software for that matter). So, I would expect them to be working on VP8 hardware decoders.
"The worst tyrannies were the ones where a governance required its own logic on every embedded node." - Vernor Vinge
I would disagree. The competition locks themselves out by keeping the best quality codecs closed source. If Google can equal the quality of an expensive codec, and make if open source with no royalties paid by anyone to anyone, that's great. But, don't blame Google for locking anyone out! It's still a "free market". Anyone can make an even better codec, and sell it for less!
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
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
oh please. there are plenty of open kernels and open graphics systems available.
this VP8 thing prevents the internet from having to deal with yet another proprietary roadblock.
it was going to happen anyway with h264 in another 10 years. Now we have a technologically advanced codec and don't have to screw around with parasites wanting to milk the internet.
way to go google.
besides, If you really do want to keep the ecosystem going, then start contributing to dirac, and figure out some way to make it work faster on slower hardware.
The problem is, video codecs *ARE* a case of interoperability.
Video codecs end up in *HARDWARE* on mobile devices. Once you put them there, you're kinda stuck with that, and need to buy a new device to change codecs. Picking a good codec at first is generally a good idea there. ;)
Also, let's say people can freely install codecs as they choose. You'll get websites saying you need to download this codec to watch this video, and people will do it. With a standard codec, if a site does that, users can be educated that they shouldn't download ANY codecs.
that's all.
Considering that H.264 is used in Blu-rays, ATSC, DVB-T/DVB-S2, video streaming services like Netflix and of course, sites like YouTube, I don't think H.264 will go away anytime soon.
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.
Consider the flipside, designing a codec is Really Hard Work. Google also has Really Deep Pockets. By doing this they have effectively dumped a codec that is good enough onto the market. While part of me is cheering that Google is taking one of the team in terms of opening their codec up they have basically ensured that only someone else with equally deep pockets has the time and money to engineer something so clearly better that they can recoup the time investment by surpassing VP8.
But can Google get Safari and IE on board?
What?
Just make it the default format for Youtube, and everyone will include it, just to get rid of Flash. Apple hates Adobe, and Microsoft merely dislikes it, so no tears are going to be shed.
Contrary to the popular belief, there indeed is no God.
"only someone else with equally deep pockets", or a group of someone's who has the time, expertise, and coordination to do it for free. Like, maybe, Open Source?
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
The whole discussion is moot in my opinion. Hear me out.
What do we need of online video?
Well, it should be ubiquitous. Everyone should have it available, or else web developers will be chasing their tales. FLV was a nice improvement over years gone by where a web developer couldn't predict with any accuracy what video playback facilities would be available to any particular user.
Sites like Youtube, break.com, theonion.com, are almost entirely based on online video and are only possible if most viewers can view the content with minimal fuss.
A codec doesn't need to be perfect. It just needs to be free as in beer, and everywhere. Flash did it, but it was proprietary and people didn't like it. Ogg Theora is free(in all the ways that matter, shut up Theo), but you'll never get native support for it from Microsoft.
To meet the needs of everyone, Google is giving us all VP8. It may not be the best, but if it's freely available to all browsers(native ideally, or by plugin), then it meets the needs of the web developer community to avoid recreating the wheel for every browser.
You can't legislate goodness. Let each to his own destiny, by will of his freely made choices.
Your hypothesis fails the falsification test. Basically no matter what Google does, people like you are going to say they did it for their direct advantage.
To make it a scientific opinion, you have to give an example of an action that Google will take that will convince you they were not evil. Sometime ago, slashdotters were saying that if Google open sources VP8, that would be proof enough. Apparently you want more. So tell us. What do you want?
First, I doubt that it will lock out competing codecs. At best, it will create a common interchange format. There's no reason why software wouldn't continue to support whatever codecs were useful to people. The only thing it might do is make it hard for patent holders on other codecs to get people to pay for licensing fees, if there's a superior royalty-free format available.
I also disagree that video codecs aren't "infrastructure". In my opinion, all file formats are infrastructure and are required for interoperability and compatibility. People can freely dream up new applications while still standardizing the formats those applications output to.
But finally, I disagree with the implication that your "second type of Free Software" should be considered a threat to a competitive ecosystem. Firefox hasn't locked out competing browsers and OpenOffice hasn't locked out existing office suites. MySQL hasn't locked out all other databases. Other FOSS can compete, and they can even start by forking the existing project. If proprietary software is superior enough that people are still willing to pay for it, then people will buy it. FOSS isn't a threat. to anyone doing a good job. It's only a threat to companies who want to rest on their laurels and rely on vendor lock-in to make a profit.
The GPL is not the only reason that Firefox would decline to place an encumbered technology in their browser. However, you are incorrect in stating that GPL2 would allow this. Under the terms of GPL2 section 7, the only allowable patent license would be one that licenses all GPL software used by anyone, because the patent license you take may not restrict any of the GPL terms - like modification, and of course you can modify any GPL program into another GPL program.
Bruce Perens.
H.264 is in *everything*, even Flash. It's in all the hardware, from smartphones to PC GPU's. Camcorders make it. It's on Blu-Ray and iTunes and YouTube.
This move with VP8 is likely to keep MPEG licensing free from 2016 through the expiration of the patents. It's not going to displace H.264, though. Even if everyone in the world agreed to replace H.264, it would take a decade or more. Even if you don't know it, most of the post-DVD video you've watched was H.264.
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.
Compared to the original On2 codec? It has. Who says the same same can't be replicated with VP8?
Indeed!
.... google can also just implement the new codec on youtube... the whole world will follow.
ensured that only someone else with equally deep pockets has the time and money to engineer something so clearly better that they can recoup the time investment by surpassing VP8.
Not at all. The cheapest and easiest way to surpass VP8 is simply to take VP8 and improve it. Minor investment, not that much to recoup that it's a problem. If you have a problem that needs a better codec, it might even pay for itself.
It's the restrictions of patents and copyrights that make that difficult; they make it harder to engage in mass reuse, necessitating the massive investment of rewriting things from scratch. Copyleft ameliorates the problem, but nowhere near as effectively as outright abolishing intellectual monopoly rights would.
We, the casual pirates, disagree.
We want movies. We don't give half a shit regarding what format it is encoded, in, so long as it plays.
We don't even particularly care about image quality. If anyone cared about the difference between Theora and h.264, blu-ray would be flying off the shelves, instead of slowly trickling out despite major pushes. In terms of media, society has consistently favoured quantity and story quality over "image quality". basically: if you can get more of it, people like it.
We, the casual pirates, dislike region codes, release dates, and "waiting for the dvd", in an age where none of that is necessary. We want to watch movies, and if no one is willing to sell them to us in a format we can easily consume, we will acquire them through other means.
We have never cared what the hell "h.264" means.
You are lying.
The word here is "wrong", not "lying".
You do not accomplish anything by accusing this this person of deliberate misinformation, aside perhaps from making yourself appear a dolt.
Hmm, let's try to put it into a computer software context. If the only optimization level your compiler had was "-Op" which did perfect optimization by doing a brute-force search over all possible sequences of machine code of a certain size (let's assume that the input data distribution is known), but using this compiler option then required several years of computer time to finish the compilation, this wouldn't be "good" (i.e., useful) in most scenarios, and no one would do any optimization at all.
In other words, attaining (or even trying to attain) perfection in a specific goodness metric almost always causes other goodness metrics to give very non-optimal results. Another example of this is the "over-fitting" problem in machine learning.
There's no bigger software patent problem than the video situation, and Google's track record is good. They stockpile software patents, but I haven't found any cases of them using their patents aggressively. 29 patent holders are claiming to have a total of over 900 patent on h.264! There's just no way to invalidate them all.
The only way we can win this is by abolishing software patents (I'm working on it, but it won't happen tomorrow :-), convince everyone to move to Theora, or convince everyone to move to some super new format.
Expert in software patents or patent law? Contribute to the ESP wiki!
Also note that perfection is exceedingly rare and tends to be exorbitantly expensive when it is accomplished. Solutions that meet a need well enough for a reasonable cost are usually all that's necessary. A company could go broke or a person could die of old age looking for perfection because they refuse to release a "good enough" solution. Even when seeking perfection, releasing "good enough" early enough and improving from there tends to be much more useful than paralyzing yourself refusing to compromise anything from your perfect solution.
It can have to do with trying to displace a "good enough" solution that's already out. It doesn't have to. If that was the only reason or the saying, it would probably be worded "The enemy of the perfect is the good" instead. Too often, we never see a promising project because some minor drawback we could work around easily delays its launch.
Software development teams often use continuous integration, time boxing, iterative development, and many of those other agile buzzwords to prevent the exact problem this saying codifies. The whole point of "agile" development (as well as lean manufacturing and many other modern productivity boosting systems across industries) is that you pay attention to the quality of the pieces as you build them and put the pieces together rapidly into a quality whole that doesn't necessarily have more than the most essential features. Then you release, then refine both the pieces and the whole, then release again with more features and any bug fixes.
"Agile" methods are opposed to top-down methods like waterfall which involve specifying and developing whole fully-featured projects before release, often with little feedback from the target users between specification and release. A good development team can do good work under a strict release-once mentality, but it's much easier to miss your mark with one big go at it rather than a bunch of refinements.
Open Source has consistently failed to produce anything remotely like a decent video codec so far. The only serious attempt is Theora, and that was commercially developed and donated as open source once it was irrelevant, and then people just polished it up a bit.
Codec design is hard, lots of work, and boring. It's exactly the kind of thing open source developers are bad at.
On2 VP8 already is a runaway success. Video content producers with an older version of Flash have an On2 VP8 encoder already. This is the format that Flash used just before moving to H.264