Linked by Thom Holwerda on Tue 29th Jun 2010 20:13 UTC
Multimedia, AV "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."
Order by: Score:
Comment by mtzmtulivu
by mtzmtulivu on Tue 29th Jun 2010 20:26 UTC
mtzmtulivu
Member since:
2006-11-14

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.

Reply Score: 3

Talent
by soulrebel123 on Tue 29th Jun 2010 20:31 UTC
soulrebel123
Member since:
2009-05-13

So quickly, with so few lines of code. That's open source and the best coders are there.

Reply Score: 2

Comment by Kroc
by Kroc on Tue 29th Jun 2010 21:52 UTC
Kroc
Member since:
2005-11-10

Sharing code with the H.264 implementation, awesome! The MPEG-LA will love that.

Reply Score: 4

RE: Comment by Kroc
by Lazarus on Tue 29th Jun 2010 22:34 UTC in reply to "Comment by Kroc"
Lazarus Member since:
2005-08-10

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.

Reply Score: 4

RE: Comment by Kroc
by umccullough on Tue 29th Jun 2010 22:55 UTC in reply to "Comment by Kroc"
umccullough Member since:
2006-01-26

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.

Sharing code with the H.264 implementation, awesome! The MPEG-LA will love that.


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.

Reply Score: 6

RE: Comment by Kroc
by Neolander on Wed 30th Jun 2010 08:33 UTC in reply to "Comment by Kroc"
Neolander Member since:
2010-03-08

To everyone answering this post, I think you're missing the point. For me, this...

Sharing code with the H.264 implementation, awesome! The MPEG-LA will love that.


...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.

Reply Score: 2

RE[2]: Comment by Kroc
by danieldk on Wed 30th Jun 2010 10:48 UTC in reply to "RE: Comment by Kroc"
danieldk Member since:
2005-11-18

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.

Reply Score: 2

RE[3]: Comment by Kroc
by WereCatf on Wed 30th Jun 2010 11:58 UTC in reply to "RE[2]: Comment by Kroc"
WereCatf Member since:
2006-02-15

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.

Reply Score: 5

RE[2]: Comment by Kroc
by miker on Wed 30th Jun 2010 14:21 UTC in reply to "RE: Comment by Kroc"
miker Member since:
2009-07-08

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.

Reply Score: 1

RE[3]: Comment by Kroc
by Rahul on Fri 2nd Jul 2010 13:00 UTC in reply to "RE[2]: Comment by Kroc"
Rahul Member since:
2005-07-06

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.

Reply Score: 1

RE[2]: Comment by Kroc
by umccullough on Wed 30th Jun 2010 14:28 UTC in reply to "RE: Comment by Kroc"
umccullough Member since:
2006-01-26

...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.


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.

Reply Score: 2

RE[3]: Comment by Kroc
by lemur2 on Wed 30th Jun 2010 23:42 UTC in reply to "RE[2]: Comment by Kroc"
lemur2 Member since:
2007-02-17

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

Reply Score: 2

v Hmmmm ... we have a disconnect somewhere
by lemur2 on Wed 30th Jun 2010 00:16 UTC
umccullough Member since:
2006-01-26

FTA: "because FFmpeg's Theora and Vorbis decoders are widely regarded as superior


FFmpeg's built-in Vorbis encoder produces low enough quality output to be considered broken.


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.

Reply Score: 5

FishB8 Member since:
2006-01-16

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

Reply Score: 3

lemur2 Member since:
2007-02-17

The page you link to is in reference to the encoder. The blog was referring to the decoder. Two totally separate chunks of code.


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

Reply Score: 1

umccullough Member since:
2006-01-26

The other possibility is that one group has an agenda to make the other group look bad. ;)


Or perhaps Xiph simply cares more about encoding accuracy while FFmpeg cares more about decoding performance.

Why must there be a conspiracy?

Reply Score: 4

henderson101 Member since:
2006-05-30

Or perhaps Xiph simply cares more about encoding accuracy while FFmpeg cares more about decoding performance.


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.

Reply Score: 1

Rahul Member since:
2005-07-06

The bad encoder in ffmpeg definitely does hurt the reputation of Ogg, Vorbis and Theora as well. It does affect end users

Reply Score: 3