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 466331
To read all comments associated with this story, please click here.
RE: Things we already knew about
by lemur2 on Wed 16th Mar 2011 04:23 UTC in reply to "Things we already knew about"
lemur2
Member since:
2007-02-17

From his conclusion:

>comparisons in quality are always somewhat subjective

No, they're not. Just use a pixel difference utility and do it objectively. For my tests I use this: http://pdiff.sourceforge.net/

>encoding speed to quality ratio with x264 ‘baseline’ at the higher quality settings

So basically he's telling us that you have to push the encoder (and your CPU) extra, to just get "h.264 baseline" quality out of it. This is not competitive.

>the gap never exceeds around 50% encoding time

Which is huge for a service like Vimeo or Youtube, that get thousands of encoding requests per minute. Time is money, and this would be a huge waste in resources.

>expect vpxenc to take around twice as long to encode a video of comparable quality to a x264 ‘high’

Yup. Not good good enough. Not for video services, not for mobile applications that might or might not have a DSP for webm, and definitely not good for professionals. Remember, it's the professionals who upload video that the majority of people watch. Webm is only good for people who don't mind the extra time, as long as they can do it for free. For example, a screencast of someone in his bedroom showing the new Gnome3, and uploading on his own blog bypassing youtube. These are people who do niche video that don't matter in the grand scheme of things.

WebM won't make it, in my personal, and professional opinion as a videographer. I wish it did, because I hate MPEG-LA and all they stand for, but there is no h.264 killer out there. Except h.265 that is, that comes out in 2013.

Of course, just like in the past, for my Ogv vs h.264 article, people will say that quality/speed don't matter as long as it's Free, but that's not true at all. Professionals in my field don't like h.264 for a variety of reasons, but they like webm even less.


Most of the optimal methods for video are patented by other parties, so WebM must use sub-optimal methods. There has to be a compromise made somewhere, and WebM has made this compromise in the encoding speed.

WebM has probably surpassed H264 now in quality/bit, because it was only just behind h264 by that metric at launch, and WebM has improved quality/bit by 12.8% over its two releases since then.

However, only in the last release was any attempt made at improving the quality/encoding time.

http://blog.webmproject.org/2011/03/vp8-codec-sdk-bali-released.htm...

The recent Bali release improved encoder speed significantly, but it is still not close to x264 on this metric (and this metric alone).

Perhaps the next (Cayuga) release will make up more ground by Q2, 2011:
http://blog.webmproject.org/2011/03/next-up-libvpx-cayuga.html

We will continue to focus on encoder speed in Cayuga. Though our Bali encoder is up to 4.5x faster than the initial VP8 release (at "Best" quality mode), there are more speed improvements to be had. As always, we'll continue to improve video quality in the encoder.


However, it must be said that encoder speed is the area where webM does make a (necessary) compromise, and it may never catch up with x264 (for this metric alone, since webM has already caught up in terms of quality/bit).

It is perfectly reasonable for this to be the area in which a compromise is made, because for every time a digital video is encoded it is played on average many thousands of times, and likewise for every person who encodes digital videos there are many thousands who merely view them.

For professional and high-volume use, perhaps the solution to the encoding speed problem will be found in a hardware encoder:

http://blog.webmproject.org/2011/03/introducing-anthill-first-vp8-h...

AFAIK there is also a project underway to implement WebM encoding via contemporary GPUs (shaders) using the OpenCL language, which if completed would also become a means (usable by anyone with a 3D-capable GPU) to considerably speed up the WebM encoding time.

Edited 2011-03-16 04:38 UTC

Reply Parent Score: 6