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.
Thread beginning with comment 465365
To read all comments associated with this story, please click here.
One request...
by galvanash on Wed 9th Mar 2011 01:03 UTC
galvanash
Member since:
2006-01-25

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.

Reply Score: 3

RE: One request...
by lemur2 on Wed 9th Mar 2011 01:36 in reply to "One request..."
lemur2 Member since:
2007-02-17

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 don't understand where you get this "bad" idea from. When it was released, comparisons between WebM and H264 showed that WebM was only slightly behind the best H264 encoder (x264) in quality. WebM has improved over 12% in objective quality since then, and significantly in subjective quality as well.

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.


WebM is fast enough to encode at acceptable quality to be used real time:
http://blog.webmproject.org/2011/02/vp8-for-real-time-video-applica...

Improvements in webM are ongoing:
http://blog.webmproject.org/2011/03/next-up-libvpx-cayuga.html

I'm pretty sure that the original encoding speed comparisons compared hardware-accelerated H264 against software-only WebM encoding.

Hardware acceleration of WebM encoding is now becoming available in production hardware with the Nvidia Tegra 2 platform, and ARM Platforms with Neon extensions.

http://www.arm.com/products/processors/technologies/neon.php

As far as I know, there has never been an apples-with-apples comparison of the two using equivalent levels of support.

Edited 2011-03-09 01:44 UTC

Reply Parent Score: 9

RE[2]: One request...
by galvanash on Wed 9th Mar 2011 04:07 in reply to "RE: One request..."
galvanash Member since:
2006-01-25

I don't understand where you get this "bad" idea from. When it was released, comparisons between WebM and H264 showed that WebM was only slightly behind the best H264 encoder (x264) in quality. WebM has improved over 12% in objective quality since then, and significantly in subjective quality as well.


Dude... I USE webm. And I am not talking about quality at all, only speed.

WebM is fast enough to encode at acceptable quality to be used real time:
http://blog.webmproject.org/2011/02/vp8-for-real-time-video-applica...


Anything is fast enough if you throw enough hardware at it and set the presets right. The statement that it is "fast enough" for realtime encoding simply doesn't mean anything relative to other codecs.



I know that, and I appreciate them immensely. I am a supporter of the format. 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.

I'm pretty sure that the original encoding speed comparisons compared hardware-accelerated H264 against software-only WebM encoding.


No. They were not. It was x264.

Hardware acceleration of WebM encoding is now becoming available in production hardware with the Nvidia Tegra 2 platform, and ARM Platforms with Neon extensions.


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.

As far as I know, there has never been an apples-with-apples comparison of the two using equivalent levels of support.


I will happily post a comparison as soon as I get Bali working.

Reply Parent Score: 5

RE[2]: One request...
by _xmv on Wed 9th Mar 2011 11:00 in reply to "RE: One request..."
_xmv Member since:
2008-12-09

i'd like to add that the neon support in x264 is rather limited - although i don't know the extend of optimization for neon in webm.

(not saying x264 is worst or something we all know its an _excellent_ encoder - the best in fact, but let's not make the mistake to think its perfect in every single way)

Reply Parent Score: 2