Linked by lemur2 on Wed 9th Mar 2011 00:18 UTC
Multimedia, AV The WebM project Blog has announced an update release of the VP8 Codec SDK codenamed the "Bali" release. The Bali release was focused on making the encoder faster while continuing to improve its video quality.
Permalink for comment 465401
To read all comments associated with this story, please click here.
RE[3]: One request...
by lemur2 on Wed 9th Mar 2011 05:36 UTC in reply to "RE[2]: One request..."
Member since:

However, overstating the facts doesn't help anyone. Webm was and is not "slightly" slower than x264, it varies depending on the presets, the source materials, and the number of cores you have, but for Aylesbury it is still about 5-10 times slower when run single threaded on MY source files... Running it multi-threaded affects quality negatively (at least it did in Aylesbury), x264 does not suffer from that issue. Running them both multi-threaded closes the gap to about 3-6 times slower, but it is still ALOT slower.

WebM encoding is indeed considerably slower than x264, I didn't say otherwise. Here is what I did say:
When it was released, comparisons between WebM and H264 showed that WebM was only slightly behind the best H264 encoder (x264) in quality.

Now H264 has patents on many of the most optimal methods, so in order to approach H264 in quality, there is a tradeoff. WebM decoder speed is not traded off, in fact WebM decoding is less computationaly expensive than H264. Encoding speed is where the compromise was made. webM encoding is indeed a lot slower, that is how it can make up ground in quality while being forced to use less-than-optimal methods.

That will certainly help, but my point about not reporting real performance still stands. I'm not ragging on the state of webm - it is what it is and it will get better. I simply don't see the point of not reporting absolute performance.

The real question is "what is acceptable"? Given there must be a compromise somewhere, where should any sacrifice of performance be made? Given that most people will only ever encode relatively few video clips, and that video clips are typically encoded once per many thousands of times they are decoded, it makes sense that the performance compromise should be made in the encoding. The Bali release makes this sacrifice a good deal less painful than it was in the previous two releases of WebM.

For people who do have a lot of WebM encoding to do, the best solution at this time is to obtain a platform with support for encoding in hardware. At this time there are two hardware solutions for encoding, they are the Nvidia Tegra 2 platform and "ARM with Neon extensions" platforms.

There is also AFAIK a work in progress to provide wider support for hardware accelerated WebM encoding via GPUs using the OpenCL language, but that is not yet useable at this time AFAIK.

Reply Parent Score: 4