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.
Compared to the initial launch release (May 19, 2010), and the previous release codename Aylesbury (October 28, 2010), the new Bali release achieves the following improvements:
- “Best” mode average encoding speed: On x86 processors, Bali runs 4.5x as fast than our initial release and 1.35x faster than Aylesbury.
- “Good” mode average encoding speed: Bali is 2.7x faster than our initial release and 1.4x faster than Aylesbury.
- On ARM platforms with Neon extensions, real-time encoding of video telephony content is 7% faster than Aylesbury on single core ARM Cortex A9, 15% on dual-core and 26% on quad core.
- On the NVidia Tegra2 platform, real time encoding is 21-36% faster than Aylesbury, depending on encoding parameters.
- “Best” mode average quality improved 6.3% over Aylesbury using the PSNR metric.
- “Best” mode average quality improved 6.1% over Aylesbury using the SSIM metric.
Note that the Aylesbury release itself achieved over 7% overall PSNR improvement (6.3% SSIM) over the launch release. This brings the total improvement in the SSIM quality metric for the Bali release to 12.8% improvement over the launch release. Most of the image quality and encoding speed comparisons posted online comparing WebM and H.264 compare the launch release of WebM, not the Aylesbury release and certainly not this new Bali release.
I appreciate Google posting these updates. This is the 2nd one they have done so far in a fairly short amount of time so that are at least demonstrating some determination in making webm better.
However, I _really_ wish they would give some indication of actual performance instead of just reporting everything relative to the last release. The relative stuff is useful, don’t get me wrong, but the lay person reading this has no idea how the webm encoder actually performs…
I suspect they don’t want to do so because performance is still so bad, but facts are facts and they shouldn’t hide them. I want to see webm get used more, but the sad fact is that although the encoder is now 4.5 times faster than it originally was, it is still over 15 times slower than x264 even using best case comparisons for webm.
They have a looonnnggg way to go. Achieving encoding speed parity (or at least being in the same zipcode) is a key requirement for adoption by most users I would think.