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 466466
To read all comments associated with this story, please click here.
galvanash
Member since:
2006-01-25

How much difference is there between a PSNR of 39 and 45? Numerically that's only a 12% difference, at most.


It doesn't matter to me, I am firmly in the "PSNR is meaningless" camp and just ignore PSNR scores. It is somewhat useful for selecting a optimal bitrate constraint for particular source material, but for comparing quality across codecs it just doesn't mean anything.

There is also the issue that there is only a 4% difference between the best x264 settings and the baseline. Saying that WebM can only keep up with the x264 baseline really isn't saying anything bad.


I am a webm supporter, but a spade is a spade and that statement isn't fair to x264. A 4% difference when you are using a low resolution source with a highly constrained bitrate is meaningless... Try the same video at 720p with a reasonable bitrate (say 1500kbps) and that 4% will turn into upwards of 10-20% real quick. x264 main and high profile produce much better quality than baseline at high resolutions with comparable bitrates. That is frankly what those profiles are for (i.e. trade higher decode complexity for increased quality at high resolutions).

You can't take the 4% swing on a 320x240 source file at such a low bitrate and form a conclusion like that from it.

The only thing this data proves is that WebM NEEDS a multi threaded encoding machine.


You are reading too much into that. It needs multi-threading to get within the "twice as slow" range compared to x264, but x264 is multi-threaded by design and by default - webm's multi-threading support is rather poor and hurts quality rather significantly (unfortunately). x264 quality is virtually unaffected by multi-threading. In reality webm needs "better" multi-threading support, using threads to make it faster as things are now is something of a crutch that doesn't work all that great (but granted it is better than nothing).

I am sick and tired of hearing people declaring that professionals are never going to support WebM. Google owns the largest video site and they choose WebM. They obviously can make it work.


Google is a content distributer. They are not video professionals by any stretch of the imagination. When people like me say "professionals will never support webm" we are talking about content producers, not distributors. And I still don't think professional content producers will ever embrace it, but I also don't think it actually matters much either. It is a fine distribution format, at least as good as x264 baseline and getting progressively better with each release. Who cares if content producers use it? It doesn't much matter - any video is just a re-encode away from being free from the grips of MPEG-LA...

Granted, Eugenia lumps content producers in with distributors (even online distributors), but that is her bias since she works in the industry. I frankly don't see it that way at all.

Edited 2011-03-17 00:17 UTC

Reply Parent Score: 3