Linked by Thom Holwerda on Sun 23rd May 2010 09:41 UTC
Benchmarks Now that Google has opened up VP8, the big question is obviously how it'll hold up to H264. Of course, VP8 already wins by default because it's open source and royalty free, but that doesn't mean we should neglect the quality issue. Jan Ozer from StreamingMedia.com has put up an article comparing the two codecs, and concludes that the differences are negligible - in fact, only in some high-motion videos did H264 win out. As always, this is just one comparison and most certainly anything but conclusive. Update: Another comparison. I can't spot the difference, but then again, I'm no expert.
Thread beginning with comment 426149
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Comment by hornett
by Eugenia on Sun 23rd May 2010 11:11 UTC in reply to "Comment by hornett"
Eugenia
Member since:
2005-06-28

I agree. This test should have been against a well-optimized x264 command line, not a random GUI encoder that has pre-baked options. The reason for this is two fold:

1. The kind of videos people look at mostly, at Youtube & Vimeo, are using these well-optimized command lines to encode (youtube is using a modified x264 version, and Vimeo is using x264 via mencoder AFAIK). Therefore, it's these kinds of videos that will essentially matter on web video. What you and me are encoding at home will always be good enough with either encoder (really, do we need better quality recording our cats sleeping on a couch?), but web broadcasting is where the difference is made. And since these web broadcasting services are always well-optimized, I expect any benchmarking test to try to be as close as possible to the level of these web services.

2. The guy possibly did use the command line to encode to WebM, so why not for h.264 too?

I know that the x264 developer was called biased for his recent blog article that was linked from many places, however, I don't think he was lying. When he said that VP8 is possibly as good only as h.264 Baseline, I think he was truthful in that.

Still, I rather have VP8 (even on my camera, shooting directly to VP8) than have the patent nightmare and ESPECIALLY the crazy licenses for cameras/video-editors surrounding h.264.

Reply Parent Score: 8

RE[2]: Comment by hornett
by bhtooefr on Sun 23rd May 2010 11:21 in reply to "RE: Comment by hornett"
bhtooefr Member since:
2009-02-19

Also, isn't most web video H.264 Baseline anyway?

Reply Parent Score: 3

RE[2]: Comment by hornett
by Radio on Sun 23rd May 2010 11:32 in reply to "RE: Comment by hornett"
Radio Member since:
2009-06-20

2. The guy possibly did use the command line to encode to WebM, so why not for h.264 too?

No. Squish is just Sorenson's very simple online WebM encoder (whereas Squeeze is Sorenson's desktop software).
https://www.sorensonmedia.com/vp8/

Therefore the h264 version is the one most likely to have been optimized "by hand", but I don't think it is. It is also unlikely that Squeeze uses x264 because the former is licensed while the second is open-source*.

(*not in America)

Reply Parent Score: 2

RE[2]: Comment by hornett
by mtzmtulivu on Sun 23rd May 2010 19:22 in reply to "RE: Comment by hornett"
mtzmtulivu Member since:
2006-11-14

I agree. This test should have been against a well-optimized x264 command line, not a random GUI encoder that has pre-baked options. The reason for this is two fold:


... and what will you be measuring? how well the codec specs stack up against one another or how well different encoders stack up against one another?

there is a difference btw a codec spec and codec encoder. A bad spec will do badly independently of the encoder used and a bad encoder can produce a terrible video no matter how good the spec is.

Blogs like osnews should try to show a distinction btw a spec and an encoder. It will be rediculous to compare html5 spec against previous versions based on how well/terrible different browsers handle the two and it just as rediculous to compare these two codecs based on how different encoders handles them

Reply Parent Score: 5