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.
Is is really a good idea to advertise how similar VP8 and H.264 are? Send in the patent trolls.
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.
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
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.
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
It is fairly well known that the more lines of code the more prone to errors the code base can be. Therefore, the fewer lines of code, the less chance there is that a coding error will occur. If there is an error, it is easier to find than by perusing a 10k LOC or a 1000k LOC codebase.
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
Oy vay... how the heck did that get modded interesting?
Yes. VP8 is supposed to be free. And the code Google released is free. But the issues surrounding VP8 have absolutely nothing, zero, nada, to do with copyright law.
The question is: Does VP8 include technology/methods covered by patents contributed to the MPEG-LA H.264 patent pool? The fact that a huge amount of H.264-related code could be reused in their VP8 decoder strongly suggests that, at minimum, VP8 and H.264 are very similar, and that greatly increases the odds that this is the case, and that any codec implementing VP8 would violate one or more of those patents.
That's bad.
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?
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
The fact that a huge amount of H.264-related code could be reused in their VP8 decoder strongly suggests that, at minimum, VP8 and H.264 are very similar, and that greatly increases the odds that this is the case, and that any codec implementing VP8 would violate one or more of those patents.
That's bad.
OTOH, Google is a gigantic multinational with lots of money, lawyers and time to review the code, and they say it's free-and-clear of patent issues.
That's good.
tomorrow who's gonna fuss
They're guessing. It's just that simple. Heck, Microsoft said the same thing when they released VC-1, and guess what? They were quite wrong, which is why there's now a patent pool for VC-1.
No, I'll be *very* surprised if someone doesn't produce patents that VP8 violates. The only question is whether Google will be able to get the patent holders to contribute to a pool the way MS did with VC-1, so that Google can offer free or cheap licensing.