Linked by Brooss on Tue 15th Mar 2011 23:32 UTC
Benchmarks A comment on the recent article about the Bali release of Googles WebM tools (libvpx) claimed that one of the biggest problems facing the adoption of WebM video was the slow speed of the encoder as compared to x264. This article sets out to benchmark the encoder against x264 to see if this is indeed true and if so, how significant the speed difference really is.
Permalink for comment 466387
To read all comments associated with this story, please click here.
WebM vs H.264 benchmark
by WereCatf on Wed 16th Mar 2011 11:25 UTC
Member since:

I personally am much more interested in the quality aspect than in encoder speed. Unfortunately, there seems to be no quality benchmark anywhere that is actually fair to both parties; either it tries to pose H.264 as superior and thus uses inferior settings for WebM, or vice versa.

How I would like a quality benchmark to be done:
1) Have a 30min video at really high resolution and no lossy compression as the source, with a few steady scenes where it's important to preserve the colours and clarity as well as possible, a few scenes with lots of movement where it's important not to produce many compression artifacts, and then lastly low-light versions of all the afore-mentioned scenes so we can quantify how well the encoders manage low-contrast situations.
2) Find a H.264/x264 enthusiast who knows his stuff and tools to do the H.264 encoding, and a WebM/VP8 enthusiast to do the WebM encoding. It's not quite possible to avoid bias anyways, so why not just choose biased parties from the start but only let them work on what they prefer? This way both of them will do their best to get the best output they can.
3) Establish the conditions for the encoding tests, like for example bitrates as 150kb/s, 600kb/s and 1800kb/s and resolutions as 320x240, 640x480 and 1024x768, and then encode all the combinations above.
4) Upload all the resulting output files somewhere so people can make their own comparisons, but also clearly state file sizes, encoding times and any settings used and provide a few sample images from all the different conditions.

Then we could actually have some meaningful discussion without having to resort to "he is biased, he doesn't use the best possible settings!" arguments.

Reply Score: 3