User: Password:
Subscribe / Log in / New account

Static v.s. moving images

Static v.s. moving images

Posted May 26, 2010 10:10 UTC (Wed) by AndyBurns (guest, #27521)
In reply to: This is a badly researched article. by DonDiego
Parent article: Swift and predictable reactions to WebM

> Contrary to what this article claims Jason *did* post comparison images
> here are two out of many:

Given several seconds to flick backwards and forwards between the images I can see differences, but not necessarily say which is better; with 24 or 30 images per second I suspect it would be even harder to decide which is best.

(Log in to post comments)

Static v.s. moving images

Posted May 26, 2010 11:41 UTC (Wed) by paulj (subscriber, #341) [Link]

You'd likely perceive one as "sharper" than the other, even without consciously noting the extra details. Our brains are quite good at such fast, parallel processing.

Static vs moving images

Posted May 29, 2010 17:21 UTC (Sat) by giraffedata (subscriber, #1954) [Link]

You'd likely perceive one as "sharper" than the other, even without consciously noting the extra details. Our brains are quite good at such fast, parallel processing.

Actually, fast is one thing the brain is not. That's the reason that 24 frames per second is ususally indistinguishable from continuous motion.

Parallel, yes.

In this case, the most important feature of the brain is it's ability to track a moving object. It sees the object, not a series of scenes with the object in different places. So watching a ball move across the screen for 2 seconds is as good as staring at a single frame for 2 seconds for noticing how sharp the ball is.

Static v.s. moving images

Posted May 26, 2010 15:25 UTC (Wed) by DonDiego (guest, #24141) [Link]

x264 clearly preserves more detail, VP8 is blurrier. Thus x264 is better.

You are free to choose VP8 (or any other codec) nonetheless, but the quality difference is not something that can be honestly disputed.

Static v.s. moving images

Posted May 26, 2010 17:14 UTC (Wed) by aleXXX (subscriber, #2742) [Link]

Are these images from the same bitrate and quality settings ?
The 264 one is indeed much sharper, it looks like twice the resolution of the vp8 one.


Static v.s. moving images

Posted May 28, 2010 20:23 UTC (Fri) by dododge (subscriber, #2870) [Link]

From his blog post:
all encoders are optimized for optimal visual quality wherever possible. [...] the bitrate is (as close as possible to) the same on all of these files.
He also provides the motion clips the frames came from, as well as comparisons with H.264 Baseline, Theora, Dirac, and others.

The test was unfair

Posted May 29, 2010 7:47 UTC (Sat) by bawjaws (guest, #56952) [Link]

The test *is* biased, just not in brutally obvious ways. Not that I think VP8 would have won in a fair fight with x264, but in many ways that just makes it less acceptable.

The test clip benefits greatly from an x264 feature not generally found in other encoders, even other H.264 ones. He actually calls this out earlier in the article as the greatest single improvement in x264 and links to before and after images:


Notice anything familiar? Yes, it's basically the same clip that he's been tuning for, and the problems you see in the competing encoders are very similar to the ones you see in x264 before this was added (blurring in high frequency areas).

On top of that he's done the old classic of choosing the testing bitrate so that the favoured codec looks 'bad' but the competitors look 'terrible'. If you compare with the original (conveniently not provided) you'll notice that even the best x264 encode totally wrecks the human figures, making them look like the pixelated sprites from the original Mortal Kombat. If the bitrate had been increased to make x264 look actually good then the competitors would have increased quality proportionally more, if it had been dropped lower than both would have looked different shades of terrible.

You can see this effect better in the comparisons at where the bitrates where chosen to match standard Youtube sizes and bitrates. One clip, with the bee, is 'easy' so both encoders look effectively identical, while the parkjoy clip from the x264 test and another riverbed one, are difficult so both look kind of rubbish.

Maybe extreme clips and bitrates are necessary for codec quality testing when encoders start to converge in quality, and maybe comparing your known strong points against competitors' known weak points is standard practice in marketing material, but both seem out of place in an article billed as an in-depth technical analysis of a new codec. It features a single image of the codec output and it happens to be of a carefully engineered failure mode. Is it any wonder that the second most common summary of this analysis you see accompanying links to it (after "turns out it infringes H.264 patents") is "turns out it sucks".

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds