Linked by Brooss on Tue 15th Mar 2011 23:32 UTC
Benchmarks A comment on the recent article about the Bali release of Googles WebM tools (libvpx) claimed that one of the biggest problems facing the adoption of WebM video was the slow speed of the encoder as compared to x264. This article sets out to benchmark the encoder against x264 to see if this is indeed true and if so, how significant the speed difference really is.
Thread beginning with comment 466325
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Things we already knew about
by smitty on Wed 16th Mar 2011 03:37 UTC in reply to "Things we already knew about"
smitty
Member since:
2005-10-13

From his conclusion:

>comparisons in quality are always somewhat subjective

No, they're not. Just use a pixel difference utility and do it objectively. For my tests I use this: http://pdiff.sourceforge.net/

Except that certain pixels are often more important to scene quality than others. It is subjective, even if you can quantify parts of it.

Yup. Not good good enough. Not for video services,

Note that Youtube is already encoding everything in VP8, so apparently it is good enough for them.

Clearly, it has a long way to go before it catches up with x264. I don't think anyone has ever claimed otherwise. Luckily, they are continuing to release updates every 3 months and the gap will continue to close. The improvements from the original release are already significant. Also remember that all these tests tend to be against x264, which is the best in class h.264 encoder. It actually blows away a lot of the commercial encoders as well, and plenty of companies are making lots of money off them without being told their codecs are useless.

Edited 2011-03-16 03:40 UTC

Reply Parent Score: 5

Eugenia Member since:
2005-06-28

>Note that Youtube is already encoding everything in VP8, so apparently it is good enough for them.

Youtube's quality sucks. It's visibly soft on my HDTV (watching its HD videos via my Roku). Vimeo is way better, about 25% better. And youtube doesn't use webm for normal usage, it's only used as a last resort, if h.264/flash is not found.

Reply Parent Score: 2

1c3d0g Member since:
2005-07-06

That's because of people like you who refuse to move to something better and instead cling to proprietary, dead-end software. It doesn't help the fact that you are so close-minded as well.

Reply Parent Score: -1

Neolander Member since:
2010-03-08

1. The fact that Youtube is by far the biggest player of video on the web despite sucky quality shows that quality really doesn't matter on the web.
2. It is obvious that you don't know how WebM on youtube works, so you've not even tried it. Interesting...

Reply Parent Score: 5

smitty Member since:
2005-10-13

Youtube's quality sucks. It's visibly soft on my HDTV (watching its HD videos via my Roku).

Sure, but you said no video sites could use it. Obviously the biggest and most important one can.

And youtube doesn't use webm for normal usage, it's only used as a last resort, if h.264/flash is not found.

That's because it's in beta. Or don't you think that in 12 months or so they'll flip the switch and have FF/Chrome/IE9 with WMF codec default to the WebM page and have the Flash/h.264 there as a backup for mobile and older browsers? I don't think they spent all that time re-encoding their entire back library just on a whim, or as a backup. They're going to do something with that.

Reply Parent Score: 6

Beta Member since:
2005-07-06

>Note that Youtube is already encoding everything in VP8, so apparently it is good enough for them.

Youtube's quality sucks. It's visibly soft on my HDTV (watching its HD videos via my Roku). Vimeo is way better, about 25% better. And youtube doesn't use webm for normal usage, it's only used as a last resort, if h.264/flash is not found.


The quality of Vimeo does not matter, as when you visit their site in a Flash-free Firefox 4, you see a download link for Safari... seriously.

Some video is better than no video.

Reply Parent Score: 1