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 465368
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: One request...
by lemur2 on Wed 9th Mar 2011 01:36 UTC 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[3]: One request...
by lemur2 on Wed 9th Mar 2011 05:36 in reply to "RE[2]: One request..."
lemur2 Member since:
2007-02-17

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

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