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 465401
To view parent comment, click here.
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..."
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[4]: One request...
by 1c3d0g on Thu 10th Mar 2011 13:32 in reply to "RE[3]: One request..."
1c3d0g Member since:
2005-07-06

Well fucking said! I'm tired of developers whining about actually working for a change.

"Ooh, it's too slow!!!" Well guess what, do what you're supposed to do, what you're PAID to do and encode the damn video's already.

Just like web developers. "Oh noes, we have to move to a newer format (HTML5), I can't do it!!!" Well guess what again loser, get off your fat ass and code the damn website already.

If most developers were actually just slightly less lazy, we wouldn't be stuck with stupid apps that relied on outdated programs (IE6) to begin with.

Reply Parent Score: 2

RE[4]: One request...
by Laurence on Fri 11th Mar 2011 08:23 in reply to "RE[3]: One request..."
Laurence Member since:
2007-03-26

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.

This comment winds me up rotten. Not because of anything fault of yours or the WebM developers, but because of the sorry state patent laws leaves consumer choice.

I know the topic of patent protection has been done to death already, but I really do wish developers were left to write code rather than worrying about avoiding best practices because they're patented.

If someone "steals" code, then they're right to be sued under copyright law. Though that's a different case-study altogether. Patents, however, have no place in software.

</rant>

Reply Parent Score: 5