“Developers Ronald Bultje, David Conrad, and Jason Garret-Glaser are creating a native VP8 video codec implementation for the open source FFmpeg project. The aim of this effort is to bring first-class VP8 support to FFmpeg and demonstrate the feasibility of producing an independent VP8 implementation.”
This is certainly a good move. All other projects seem to be taking google’s implementation of the codec and lack of competition will do more harm than good to the codec because all inefficiencies in google’s code will go unchallenged.
Let them compete and let the best implementation win out.
So quickly, with so few lines of code. That’s open source and the best coders are there.
Sharing code with the H.264 implementation, awesome! The MPEG-LA will love that.
Indeed, tho it seems too early to be convinced at this point that that the shared code itself violates any of their imaginary property. In my not so expert understanding, anything that is shared is likely to be some very generic stuff.
Seems utterly moot anyway as I’m fairly certain that the FFMpeg folks aren’t paying the extortion money for the *actual* H.264 code they already have.
First: I have essentially zero knowledge of the patents involved with H.264, so I’m pretty much speaking from my general understanding of how patents affect open source.
MPEG-LA wouldn’t care any more than they already do – FFMpeg already uses their patented methods in order to implement x264.
So, to cut to the point – there are very likely ways to accomplish the same task without violating certain patents, by implementing something in a very slightly different manner. If the FFmpeg group chooses to use patented methods to accomplish the same task, that doesn’t necessarily mean the VP8 codec implementation that Google produced also violates those patents.
Thus: two different implementations that produce the same end results may violate different sets of patents. It is FFmpeg’s choice to use existing x264 code to produce a VP8 implementation, and it’s possible that users of FFmpeg’s VP8 implementation could be at higher risk of patent infringement than those using Google’s implementation. Google only has to demonstrate that it is possible to implement the codec without violating patents in order to make the codec “safe” and viable – and if other vendors choose to implement patent-encumbered implementations of the codec, it becomes their users’ choice and risk to use them.
This is yet another reason why software patents are absurd.
To everyone answering this post, I think you’re missing the point. For me, this…
…point out that any program who use the FFmpeg implementation of the VP8 decoder will get a patent-encumbered H.264 decoder bundled with it.
No matter whether the H.264 code actually violates patents or not, it will give them some fodder to claim that VP8 is a cheap H.264 ripoff.
My personal interpretation is that many of the techniques are apparently so universal or generic that they should not be patentable, even in a system with software patents.
No matter whether the H.264 code actually violates patents or not, it will give them some fodder to claim that VP8 is a cheap H.264 ripoff.
VP8 is atleast partially based on their older codecs, all the way to VP3, and there most likely exists several old patents regarding the tech used. So, while H.264 itself might predate VP8 the patents would still predate H.264, and it’s highly likely that H.264 violates atleast some of them.
I dare say that the reason why MPEG-LA hasn’t yet gone to court is that they know Google now holds patents that’d render H.264 illegal and thus suing them would mean a suicide. No, MPEG-LA will just resort to spreading FUD and hoping that repetition will have the same effort as it usually has: people will start to believe it. Google on the other hand just sits back and enjoys the drama, atleast for now.
No, just because the share code doesn’t mean every codec has to be bundled, it will be trivially easy to produce an ffmpeg build that supports vp8 but not h264.
Unfortunately, unlike Gstreamer, such support is a build-time rather than runtime option since ffmpeg does not have a concept of plugins and therefore a number of major distributions do not include ffmpeg in their primary repositories because they cannot include some of the patent encumbered ones, which is a shame really. Alteast these days ffmpeg seems to have a regular release schedule.
And honestly, we don’t even know what code is being shared. Perhaps it’s all the non-patented stuff like colorspace conversion and container parsing stuff. Of course, much of that would be used for more than just h.264.
Also, I suspect more of the patents apply to the encoding of h.264 rather than the decoding – since that’s when you apply all the special algorithms to determine the best way to compress the video with the highest quality, etc.
When one looks at a video encoded in VP8 and compares it to H.264, as they run at normal speed they are very comparable in terms of perceived quality. When one looks at the same videos frame by frame, however, one sees different effects.
For example, in still frames VP8 has quite blurry areas where parts of the image are moving (especially if there is fast movement), where H.264 has quite sharp images in the same areas, but they exhibit artefacts (things which aren’t really there, such as fringes). Since the eye sees fast movement as blur anyway, and an normal speed video camera will take blurred images when there is movement, these “defects” in the still frames aren’t really of any consequence to the quality of the running video, but they do show up where the compromises in compressing the data have been made.
The real point here is that those compromises, the actual “special algorithms to determine the best way to compress the video with the highest quality”, are quite different in VP8 to H.264.
It seems to me quite possible that these two codecs don’t actually impinge on each others patents.
Edited 2010-06-30 23:44 UTC
FTA:
Quality alert from the Planet Xiph developer’s blog:
http://xiphmont.livejournal.com/51160.html
Serious disconnect there, one would think.
Nah, one claims the decoder is better, while the other claims the encoder is garbage
Two completely different discussions it seems.
The page you link to is in reference to the encoder. The blog was referring to the decoder. Two totally separate chunks of code.
Edited 2010-06-30 02:29 UTC
Perhaps the bad decoder is playing files from the good encoder, and vice versa … then they would both be right.
The other possibility is that one group has an agenda to make the other group look bad.
Edited 2010-06-30 03:37 UTC
Or perhaps Xiph simply cares more about encoding accuracy while FFmpeg cares more about decoding performance.
Why must there be a conspiracy?
Exactly. The real question is – will the end user perceive any noticeable difference? If so, one or the other sides has a point. If not, they are bickering over nothing.
The bad encoder in ffmpeg definitely does hurt the reputation of Ogg, Vorbis and Theora as well. It does affect end users