Slashdot Mirror
VP8 Codec Coming To FFmpeg
Jim Buzbee writes "Interested in Google's VP8 codec? Well, so were the FFmpeg guys, so they went ahead and wrote their own native decoder in only 1,400 lines of unique code. They were able to keep the line-count low by relying on heavy reuse from the existing H.264 codebase."
Is anyone else worried by..
They were able to keep the line-count low by relying on heavy reuse from the existing H.264 codebase."
I bet the MPEG-LA will see that as proof that it violates their patents.
"They were able to keep the line-count low by relying on heavy reuse from the existing H.264 codebase."
Come on guys, that's not helping.
Is is really a good idea to advertise how similar VP8 and H.264 are? Send in the patent trolls.
...chances? "heavy reuse from the existing H.264 codebase." I am quite aware that this isn't any sort of definitive proof of VP8 being derivative, but it sure qualifies as a red herring ;).
Is anyone else worried by..
They were able to keep the line-count low by relying on heavy reuse from the existing H.264 codebase."
I bet the MPEG-LA will see that as proof that it violates their patents.
From tfa:
since H.264 (the current industry standard video codec) and VP8 are highly similar, we can share code (and more importantly: optimizations) between FFmpeg’s H.264 and VP8 decoders (e.g. intra prediction).
and wrote their own native decoder
It sounds like more of a dec than a codec.
You misunderstand patent law. Patent law does not require that proof that VP8 is a derivative of H.264. Patent law only requires proof that VP8 uses processes and techniques that are substantially similar to those claimed in the patents for H.264.
OTOTH, in any lawsuit involving those patents, the H.264 patent holders will have to prove that those claims are novel (no prior art) and that even if they were novel, that were not already obvious to someone skilled in the art. And since we're talking about Google, I'm pretty sure they won't have any trouble hiring competent legal counsel should such a lawsuit be brought.
My blog
I think that it has been well understood, for some time, that VP8 is, by design, largely H.264-esque. Based on that "technical analysis of VP8 by an x264 developer" article that ran on slashdot shortly after Google's announcement, it would appear that the development strategy went more or less like this:
1. Examine H.264
2. Where the technique in question is not patent-encumbered, or patent encumbrances can be worked around, implement like H.264 did. Unless you have good reason to believe the contrary, your brilliant innovation probably isn't, and the guys who build decode silicon/write DSP firmware are not handing out prizes for novelty for its own sake.
3. Where the technique in question is patent-encumbered, and the encumbrance cannot be compatibly worked around, implement the least-worst alternative.
4. Get purchased by Google.
Obviously, from a standpoint of legal defense and market acceptance, a codec of breathtaking novelty and power, looking like an algorithmic refugee from the comp-sci genocides of the 32nd century, would be preferable. Unfortunately, such isn't available by any known means. H.264 more or less represents the present consensus on best available technique in the field; but is heavily patent encumbered. The only real reason to deviate from it is to avoid patents. Assuming that they did, in fact, perform steps 2 and 3 correctly, they will have achieved approximately the best available result at the lowest possible cost.
OTOTH, in any lawsuit involving those patents, the H.264 patent holders will have to prove that those claims are novel (no prior art) and that even if they were novel, that were not already obvious to someone skilled in the art. And since we're talking about Google, I'm pretty sure they won't have any trouble hiring competent legal counsel should such a lawsuit be brought.
The patent's issuance is prima facie evidence of novelty (and all the other elements that are required for a valid patent). A prospective defendant would have to refute that presumption. Hopefully the Supreme Court will make it easier to overturn software and business-method patents in the ruling for Bilski v Kappos...
Jesus, do some investigation.
The ffmpeg VP8 implementation doesn't use a single function from their H.264 support. Not a single one!
There was some arm-waving speculation that it could use something in common made by people other than the ones actually doing the work. The code they are comparing includes a f@$@# encode. The full ffmpeg VP8 implementation is ~2740 lines. The VP3/Theora implementation which shares no codec functions is 2500 lines.
What does "relying on heavy reuse from the existing H.264 codebase" actually mean? For example, if you make some kind of new a superfast array sorting algorithm for 1 project and 'reuse' it elsewhere it does not mean both projects are the same. [Of course I haven't RTFA.]
Quick way to get 30% Funny 70% Troll: defend Opera browser on
Who the heck do you think is paying for these kinds of claims to be made?
The whole post is moronic. Ffmpeg's VP3 support is smaller than VP8 code and it shares with nothing. The bink codec is 1012 lines and svq3 is 1084 lines and these are weird codecs which have almost no sharing potential. ffv1, a state of the art lossless codec is 1200 lines.
The only thing vp8 has which is all that similar to h264 is the intra prediction modes and even the x264 guy was forced to admit that the intra prediction modes significantly pre-date h264 and are thus UNPATENTABLE.
> requires proof that VP8 uses processes and techniques that are substantially similar to
> those claimed
Not even that. To be infringing, you have to be subject to _all_ the claims of the patent. "substantially similar" is not enough if there is one particular claim that doesn't apply to you.
A common way of working around a patent is to pick a particular claim from the patent and make sure that your work is not covered by that claim.
http://lists.xiph.org/pipermail/theora/2010-April/003769.html has a pretty good summary of the state of the patent situation for H.264. Especially note the paragraph starting "It doesn't have to be this way".
Not necessarily, no. Otherwise, patent attorneys wouldn't be advising their clients to do a novelty search. The results of a novelty search that do appear on a patent are prima facie evidence that the elements claimed are novel over the references listed, but again, this does not necessarily preclude the possibility of prior art and is not prima facie evidence that there is absolutely no prior art.
My blog
Since when has LOC been a good measure of software?
If VP8 is supposed to be free there can be no conflict surely. greedy mpegla owns odd coyrights on certain encoding rules not written code, right? So that a line of code ("Print 'hi!'") can be reused isn't really relevant is it?
If Google really cared they would fix Android Chrome to reflow text, instead of discriminating
On a lot of platforms, especially handheld ones, an end user can't use binaries unless the platform's gatekeeper has distributed them. It's not as if the end user can just compile his own because the resulting binaries won't have a digital signature with a verifiable chain up to the gatekeeper.
The people using the free codec are in violation, not Google.
United States copyright law has legal theories called "contributory infringement" (A&M Records v. Napster) and "inducement to infringe" (MGM v. Grokster), and I see no reason why the logic behind these theories would not apply equally well to patent law.
To be infringing, you have to be subject to _all_ the claims of the patent.
Where did you get that information? As I always understood it, only one claim of a patent has to read on a product for the product to infringe, but all elements of that claim have to be present for that one claim to succeed
> As I always understood it, only one claim of a patent has to read on a product for the
> product to infringe, but all elements of that claim have to be present for that one claim
> to succeed
Ah, indeed. I'd misunderstood where in the hierarchy of stuff in a patent "claim" sat, apparently. Thanks for the correction!
So the existing "spec" is just commented code, and even as such it is _less_ helpful than the code itself. And to think that we're letting Google write the HTML5 spec...
It's like Einstein trying to make his special relativity theory and try to avoid patents from Hendrik Lorentz for his Lorentz transformations, because in 1903 he was a poor student working in a patent office. Thank you very much America, because you try to export this stupidity all over Europe. Yes, he worked in a patent office, but in that time patents were granted only for real machines and not for math.
Imagine, if at the beginning of the computer revolution the patent offices around the world would have had granted patents on software. We would now still using Windows 3.11 or DOS, because every day-to-day technology that you are so used to would have been locked down for 20 years. Quick-Sort patented; Factory pattern patented; MVC pattern patented; and so on, you get the idea. But luckily back then nobody would even have this idea that you can get a patent on software, because every computer science student will tell you that software is just math that runs on a general purpose calculation machine.
Finally, the software that is running will _not_ change the machine, because that is for what a computer was invented in the first place. An abacus will not be transformed into something else if you calculate with it; you brain will not change if you calculate 1+1; a piece of paper will not change if you write some math. formula on it. The abacus stays an abacus; your brain is still a brain and the paper is still a piece of paper.
The H.264 algorithms are not tied to a particular machine, they are not manufacturing anything, and are not composition of matter. And they are not a process in the original meaning. But if you argue that they are a process, which takes some input and produces a result, then you opened the door to patent every math out there. Not only math, but now everything can be patented, like composition of music, writing of text and film a movie.
I'm sorry but I really don't like or want software patents in any form. I'm a software developer myself, have gone to the college and university and study I.T. That anyone could grant any patent on software is just beyond me and in my opinion the software patents are holding a whole generation of ideas and implementations thereof back in the USA and other countries which accept patents on math.
http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
But what if you don't play Final Fantasy?
Yep. One claim is all that is needed for a product to infringe, but all elements of that claim must apply in order for that claim to succeed.
As BZ is trying to say, a common workaround is to make your product so that one or more elements of each claim do not apply. This is not necessarily an easy thing to do however; it depends on how broad or narrow the given patent(s) is/are.
BTW--I am not a lawyer and this is not legal advice.
My blog
Utter nonsense. VP8 is codec number 8 of a series of On2 codecs that goes way back before H.264. Google On2 and see for yourself. On2 began marketing VP3 in 1999.
Alternative method:
1. Look at your existing technology in codec VPn that existed before MPEG LA, and think of an improvement.
2. Immediately apply for a patent on the improvement.
3. If said patent application is rejected because of an existing patent, think of another entirely method to achieve the same result, and go back to step 2.
4. If the patent was rejected due to prior art, or even better if the patent was awarded to you, then implement the improvement using the cleared methods.
5. Rinse and repeat from step 1 until a significantly improved codec emerges.
6. Release and market the new codec as VPn+1.
After a number of iterations, you have collected a few patents of your own, and developed a pretty good codec which avoids any patents which you don't own.
On one hand Google is a friend of Adobe - mutual hatred of Apple and using Flash for You Tube, bundling Adobe Flash Player in Chrome.
On the other hand Google is a strong proponent of HTML5 + VP8, which would replace Flash in some situations.
Google seems to be the master of sitting on the fence. I mean they back the biggest competitor to the iPhone (Android) and yet remain #1 search engine on the iPhone/pad/pod.
???
I am a little disappointed in VP8 and it looks like it may not be the game changer that it was touted to be. It basically comes down to the fallacy of the software patent. It scares off innovation because people are afraid of being sued. It is my belief that patents were designed to protect tangible, mechanical or electrical engineering innovations not pieces of code which drive a machine. I fully believe in the philosophy behind patenting a mechanical engineering innovation. It seems like weekly we hear about the US PTO granting a software patent for something that really isn't an innovation. The patent laws of the United States are in desperate need of reform but, then again, so are the tax and financial laws. Software patents created a group of oligarchs called the MPEG-LA.
... or alternatively, it means that Google has found that it owns patents to bits inside H.264. So then as soon as someone sues Google (or "any entity") for stuff in VP8 they lose the right to use the bits of H.264 which are covered by patents that Google acquired when they purchased on2.
Which effectively turns Google into part of the problem.
The problem, in case you weren't paying attention, is that there are too many entities (not all of them companies) who own pieces of h.264 and want to make a buck off of it.
These entities band together and hire a knuckle-dragger called MPEG-LA. MPEG-LA is a big dumb brute, and he goes out and grabs content distributors by the nuts and forces them to pay MPEG-LA, or else he'll squeeze.
If it turns out that Google/on2 also owns pieces of h.264, that doesn't mean Google can threaten MPEG-LA. It only means that Google, too, has a grip on the content distributors' nuts.
What is Google going to do, threaten to squeeze the content distributors' nuts unless MPEG-LA lets go of them? That's not only hypocritical, it's nonsensical. It's not MPEG-LA's nuts that Google has a grip on.
Actually, no, it's not prima facie evidence of anything other than the person that filed the application either got a rubber-stamp or was able to out-argue the examiner. Nothing more, nothing less.
As an example thereof, I need only point to any number of Amazon's patents, including the one they just got in this last month.
Having filed for a patent before in the past, I can assure you that while that what you say is supposed to be a requirement, even if you meet the criteria, you can have a protracted paper fight with an examiner that flipped a coin and decided to invalidate your patent- and then go looking for "patents" that "anticipate" your invention's specification, even though the guy/gal didn't do their homework and came back with a rejection that looks like the they were smoking magic mushrooms when they did the examination of your patent.
Patents are nothing of what many make them out to be in this day and age.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Is there a limit on line length?
VP8 is codec number 8 of a series of On2 codecs that goes way back before H.264. Google On2 and see for yourself. On2 began marketing VP3 in 1999.
Alternative method:
H.264 is the latest codec in a series that goes back to before On2 existed. H.261 was standardized in 1988.
But, if the original poster's speculation were true, it would put Google in the traditional role of a technology patent holder who holds a defensive arsenal of patents: if MPEG-LA makes a fuss about aspects of VP8 which they claim infringe MPEG-LA patents, then Google can threaten to retaliate by suing everyone in the world who is currently shipping an implementation of H.264 for infringement of the On2/VP8 patents (and so publicly demonstrate the fact that being an licensee of the MPEG-LA H.264 pool doesn't protect one from all patent claims, and provides no insurance or indemnity).
MPEG-LA itself admits this. The licensors' lawyers know that paying protection to MPEG-LA doesn't indemnify them.
The licensees have no choice. They're like a shopkeeper in a town full of corrupt cops. Paying bribes to one cop doesn't mean they don't have to pay another bribe to a different cop next week, but you'd better believe they're going to pay the bribe each time anyway.
Stalemate. Mutually-assured-destruction stand-off. Result: VP8 available for royalty-free for use, without MPEG-LA interference.
That's absurd. Mutually assured destruction? It's more like Russia saying to the USA, "Disarm all of your ICBMs, or we'll nuke...Nigeria!"
The MPEG-LA doesn't care what happens to its licensees
VP8 has already been dissected and determined to be a bad video codec that likely steps on several H.264 patents. Note that Google isn't providing any legal protection for using this codec.
The Wii is more than an "overclocked GameCube with a Bluetooth receiver." It has a motion-based controller, which did make it state of the art.
Wireless motion-based controllers predate the Wii; the Bluetooth receiver just lets the Wii talk to a wireless controller. Besides, you still don't see free games competing with those Wii games that don't use a lot of motion control and could have been done on the GameCube. These include that games that use shake as just a button (such as Super Mario Galaxy, apart from aiming star bits, and Animal Crossing 3) and games compatible with the Classic Controller and GameCube controller (such as Super Smash Bros. Brawl and Mario Kart Wii).
you brain will not change if you calculate 1+1;
Sorry, but actually studies of demonstrate the exact opposite. Thoughts can change the brain just as software can change the operation of a computer equipped with permanent memory.
But do continue.
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
FFmpeg's command line options are a constantly mutating, forwards incompatible clusterfuck.
Please stay away from VP8.
It can decode Vorbis. See Rockbox. What happens is that Apple won't MAKE it decode Vorbis. The Original iPod didn't decode h.264 either. Now the iPhone does. vorbis was available in hardware when the iPod was upgraded the first time and LONG before the first iPhone. Yet this wasn't included.
So it's nothing to do with "it cannot", it's all to do with "apple WILL NOT".
I'm not really able to understand the technical details of both codecs, but what I did find out is that youtube webm videos look better than their flash (h264?) counterparts even if they have nearly the same filesize. http://img243.imageshack.us/img243/985/youtubevergleich.png was a picture I made back when that blog entry was a few days old, and as you can see the webm-Video on the top in Opera looks much smoother than the normal flash based one in firefox (both have about the same filesize). It's not really possible to get the exact same frame in both videos, of course, but please trust me when I tell you that I didn't pick the best or worst pictures for either webm or the flash based video, I could see that the frames of each video are of similar quality as the one I chose in the picture when I tried to stop both videos at the exact same frame.
I also wondered why HD material and a high video bitrate(~14mbit) was used by the x264-developer to test baseline h264, VP8 and h264. Isn't it possible that 640x480 videos get compressed better in VP8 than with h264 baseline if the bitrate has to be lower? And isn't the used video (the one the pictures you linked to come from, watched it when that article came out so I don't remember it perfectly) rather 'slow motion', making it possible that VP8 is better suited for videos with fast scene changes (game trailers, mobile phone videos, ...)?
I'm not trying to spread FUD, as I said in the beginning I don't know much about this whole codec stuff. But personally I just don't see how we can really compare the subjective quality of these two (or three) codecs when both articles only show a few sample videos (only one with only one scene, or just the frames) or present them in a suboptimal way (lossy comparison pictures) :-)