To read all comments associated with this story, please click here.
What kind of details would you want ?
Because most of the web is moving towards upscaled tiny images flagged as "hd", except for vimeo ?
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.
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)
... 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




Member since:
2005-09-19
Why use Squeeze instead of x264?
Images show different times, so are they key frames we're looking at? Or intermediate frames?
Also not enough details of the encoding profiles used.
Finally, the web is moving towards HD video, how about some hi-def content instead of these tiny images?
Someone from a reputable site needs to test this properly.