This is awesome. Congratulations to the always-incredible developers of ffmpeg.
One thing is worrisome about this: 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
So it looks like VP8 is so similar to H.264 that decoders for the two can share quite a bit of code (something Jason Garrett-Glaser suggested might be the case: http://x264dev.multimedia.cx/?p=377 ). Have to admit that this doesn't seem to bode too well for VP8's claim to relative freedom from patent litigation.
Well, patents only cover the patented claims, though the lawyers try to make them cover as much as possible, which is how we get these ridiculous overreaching patents. But maybe this can be said to show that those features are, on some level, generic (i.e. not innovative/novel), and therefore the sort of thing that shouldn't be protected by patents.
That said, I certainly hope that the Bilski decision is a reasonable one, lest we end up with patented novels, grocery lists and other inane legal "innovations." Because I just can't see the MPEG-LA sitting around while Google derails their gravy train. I don't know what they'll do, but FUD and litigation seem like the most likely options. If I had to bet, I'd say that they're gathering up whatever patents they can find and waiting to see how Bilski turns out, so that they don't get shut down right at the start.
Patent lawyers working on standards like H.264 actually have incentive to make them cover as little as possible. Making the claims narrower may reduce the chance of invalidation in any potential dispute. Meanwhile, the patent needs only to cover exactly what's in the standard in order to participate in the licensing pool. As long as they match the standard carefully, implementers can't work around the patent while also remaining compliant.
Gregory Maxwell points out that this is likely applicable to H.264 and VP8:
"As we’ve pointed out before, many codec patents are exceptionally easy to work around: They specify every little detail because it makes it _much_ easier to get through the examination but doesn’t harm the patent’s ability to read on the final standard because the standard specifics exactly the patented behaviour... We can assume that in cases where VP8 looks similar to H.264 those would have been exactly the cases where care was taken to differ in the right places. I’d expect the primary risks for VP8 to be anywhere _but_ there."
On the other hand, I don't see Google sitting around while the MPEG-LA derails their gravy train. Google stands to lose a lot if they have to use a format other than VP8 or H.264 (in bandwidth costs), or if they have to pay the H.264 licensing fee for every YouTube video, Android handset, and Chrome download.
Sadly, I think Google has more to lose than MPEG-LA, because they are the company that is actually doing something useful. Patents encouraging innovation indeed...
Oh, definitely not. I have to wonder what they can do, though? They don't offer legal indemnity (probably can't, who knows how much that would cost?) and it might not be easy for them to insert themselves into any lawsuit the MPEG-LA filed.
Even though they're the obvious target, there's nothing stopping them from going after the small fry to set a precedent, or just doing a SCO-style shakedown (only they'd presumably be more competent ... at least, it'd be hard to be less competent).
If I had to bet on what's keeping the other shoe from dropping, they either are still working on finding patents that might kinda-sorta read on VP8, or they're waiting for Bilski, with some possibility of both.
But that's just my guess. I mean, who knows what they're thinking?
In fact being similar, but crucially different, to a published patented technique is apparently a good way to avoid both known and unknown patents, so this is a good thing:
I don't think vp8 makes any claims about being patent-free (that's theora). I believe the libvpx license does shield you from patent claims (meaning google will take responsibility in case of any infringement). Note that this applies to libvpx only; independent implementations such as ffmpeg's are not covered.
such license applies only to those patent claims, both currently owned by Google and acquired in the future, licensable by Google that are necessarily infringed by this implementation of VP8
You're covered unless Google decides they don't want to license one patent claim or another. Getting screwed on patents with libvpx would be something of a perfect storm, IMO. Where are the submarine claims for theora?
I believe you've misread the license. Google is granting a license to all patents they own or will acquire in the future, required for VP8 as they released it.
If you modify your own version of VP8 so it infringes some other patent that wasn't infringed by the original, you don't automatically get a license for that other patent. In other words, you can freely make VP8 implementations without worrying about Google's VP8 patents, but you can't write your own patent license for any Google-owned patent you want by writing that patent into your own version of VP8.
What you're saying has nothing to do with what I said. I will concede, however, that I missed the bitstream license, which grants some protection to independent implementations. But as others have said, that is no guarantee.
Are you referring to this: You're covered unless Google decides they don't want to license one patent claim or another.?
Google is granting a license to all Google-owned and Google-acquired patents required by VP8. Google will be the largest user of VP8, so it is in their interest to acquire or defeat any VP8-related patents that may be discovered.
You're not covered until they admit they are infringing a patent and then license it on your behalf. That wouldn't make me feel any better. Meanwhile, you're either infringing a patent or under threat of lawsuit until Google does something about it.
That's paranoia, unless you happen to be the general counsel for a Fortune 100. Because the biggest user of libvpx isn't you or me, it's going to be Google, and they're the juiciest target of any patent infringement lawsuit regarding the implementation.
If the codec works well, then just frigging use it. Google released it because they want people to use it. If you insist on peace of mind, MPEG-LA will be more than happy to take your money.
You're probably right that it's paranoia, but I just don't see any promises from Google to shield from or take responsibility for infringement; they just suggest that they could license patents in the future.
It probably wouldn't stop me but I would only do so without any sort of expectations from Google.
None of the major codec players promise to shield from or take responsibility for infringement, at least not for normal licenses. Not MPEG-LA, not Microsoft, not IEEE, not Google, not Fraunhofer.
Sometimes I feel like C programmers don't really understand reuse, but the fact that they implemented VP8 in 1400 lines of code means that I am wrong. Excellent work!
Most importantly, the spec really is a straight copypaste of the decoder’s source code. As a specification, that’s not very useful or professional. We hope that over time, this will improve.
This still baffles me. Why hasn't Google spent the effort to write up a decent spec? Are they waiting until the inevitable litigation with MPEG-LA to make their file format generic? Would this help them in litigation?
One thing is worrisome about this: 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
So it looks like VP8 is so similar to H.264 that decoders for the two can share quite a bit of code (something Jason Garrett-Glaser suggested might be the case: http://x264dev.multimedia.cx/?p=377 ). Have to admit that this doesn't seem to bode too well for VP8's claim to relative freedom from patent litigation.