Why the difference in quality? [Archive]

View Full Version : Why the difference in quality?

QuadraQ

4th October 2005, 18:35

Hi all,

I'm really impressed with the visual quality and amount of detail that x.264 is able to pull off at small file sizes (700 MB) but I find that it looses some quality in certain kinds of scenes, which puzzles me. So here are some examples:

This looks nice and sharp with plenty of detail:
http://home.mindspring.com/~quadra2/snapshot1.JPG

However you'll notice some pixelation in this shot:
http://home.mindspring.com/~quadra2/snapshot2.JPG

Here's another example...

Nice and sharp:
http://home.mindspring.com/~quadra2/snapshot4.jpg

Again pixelation:
http://home.mindspring.com/~quadra2/snapshot3.jpg

Anyway what confuses me is that it seems like the examples of a sharp image are actually far more complicated scenes, while the scenes with the pixelation are simple by comparison. Why would x.264 loose detail in these simpler scenes, that from what I can tell should be easier to handle? (You'll notice that the file size of these jpeg's are much smaller to reflect the fact that they are more compressable - is that a word?)

Maybe it's a foolish question, but it can be frustrating, when you have a nice sharp foreground and the background looks blocky.

Sirber

4th October 2005, 18:37

Bitrate? x264 do like all codecs, sacrifices. The lower quality shots are less complex, so more compressed.

4th October 2005, 18:44

This particular issue has been discussed in many threads already and there have been some suggestions on how to minimize it. I believe the developers are quite well aware of it.

QuadraQ

5th October 2005, 00:12

This particular issue has been discussed in many threads already and there have been some suggestions on how to minimize it. I believe the developers are quite well aware of it.

OK well I wasn't sure if I was the only one to run into this or not. If it's being worked on then I guess I'll just wait to see how things develop. It's almost as if the encoder sees the simplicity of the scene and drops the bitrate TOO low and then the artifacts show up.

DeathTheSheep

5th October 2005, 00:28

QuadraQ

5th October 2005, 06:11

Yes, it occurs frequently in detailed, low-contrast areas, especially those with gradients. See this thread: http://forum.doom9.org/showthread.php?t=99826

Clearly, even certain scenes exeeding 5mbps can display this sort of artifacting.

Do you think it could be following that same general pattern? Do your encodes sometimes have trouble when there is slow panning (flickering, lagging blocks)?

Yeah I think that is the same kind of issue I'm experiencing (as see in the photo examples above). The problem is actually more noticable with moving video than with the screen shots above.

If anyone in the development team wants something to test, I would recommend the opening credits of Two Weeks Notice, simply because they have multicolored blocks moving around combined with photo's which seems to really make the issue obvious. In fact, this was my very first encode with x264 and I was disapointed until it got to the live action part (then I was blown away by the detail!).

DeathTheSheep

5th October 2005, 22:56

Ah, sadly, I think it all boils down to the fact that x264 is so darn new. You'd almost think that AVC itself is so new that the awesome results it achieves so far are absurd (as opposed to the quality of ASP codecs which were worked on for half a decade).

Quite frankly, though, an "emerging codec" like x264 isn't even close to having all of its little bugs and flaws ironed out yet--at this point, development is far too heavily concentrated on actually making the codec, much less perfecting it to the extent ASP codecs are today.

Sorry, but it may be a while before that problem is ironed out. But who knows? The brilliant developers may surprise us all in no time ;)

foxyshadis

6th October 2005, 12:35

The tunings also seem to hate on blue a little more than other dct codecs, which tend to reserve their harshest judgments for reds.

Also, in both pairs, I see a roughly equal amount of blocking and ringing (pixelation), it's just much less noticable in the first halves because there's so much detail masking it. Throwing more bits at low-complexity scenes would help, but I can't remember how to make x264 do that. Also, although it's been masked away by the low bitrate, the artifacts in the first pair imply moderately heavy noise in both shots, which is always a killer (xvid would probably do similar things to it).

I would wager that custom low-bitrate quant matrixes would improve the quality noticably across the entire set.

QuadraQ

6th October 2005, 22:29

I would wager that custom low-bitrate quant matrixes would improve the quality noticably across the entire set.

How does one go about doing that? Is there a FAQ for that I could look at (I'm sure that's an advanced technique, so it's new to me.)

*.mp4 guy

6th October 2005, 23:28

You would have to use the cli version of the encoder (which you can get in the daily builds sticky) it uses MeGui as a frontend so if your familiar with it it will be easy to use, if not there are plenty of faq's on it. At the moment there are only two custom matrices that I know of for mpeg4-AVC, mine (which is aimed at 1cd type encodes) and Sharktooths (which is aimed at 2cd and better encodes) both of the matrices come with the download and can be found in the X.264 install directory.

foxyshadis

6th October 2005, 23:53

I didn't link to one because it's an "experimental" (buggy) feature in ffdshow, unless that's fixed in the last month. They do work with nero's decoder however. Right now the only readily available cqm is sharktooth's medium-high bitrate matrix, which is probably what you want; he hasn't had the time to tune much lower-bitrate versions since they're much more complicated than xvid, and ffdshow support isn't complete.

Here's his thread:
http://forum.doom9.org/showthread.php?t=96298

[edit]
didn't see mp4 guy's reply, sorry.

*.mp4 guy

7th October 2005, 00:28

Right now the only readily available cqm is sharktooth's medium-high bitrate matrix, which is probably what you want; he hasn't had the time to tune much lower-bitrate versions since they're much more complicated than xvid, and ffdshow support isn't complete.
Actually my cqm has been included in his X.264 binaries aswell since rev 293A.

akupenguin

7th October 2005, 05:04

I didn't link to one because it's an "experimental" (buggy) feature in ffdshow, unless that's fixed in the last month.
Not experimental nor buggy. Just not implemented at all.

BoNz1

7th October 2005, 06:19

Nice and sharp

Yeah, Alicia Witt does it for me too I have to admit. What a babe.

I suppose better skip detection should help in those low contrast areas. Also, you can try to adjust the weight to these scenes so they get more bitrate as these sort of scenes are often really low bitrate. Those blue and brown areas in the opening credits shouldn't move at all so they should be skipped. Although thats hard to say since I haven't seen the source ;).

QuadraQ

8th October 2005, 22:42

OK so I'd have to use MeGUI to use the custom matrices? I've been using AutoAC since it's an all in one solution. I was able to encode video using MeGUI, but I'm not sure if it does audio. It's supposed to have a mux feature, by pressing control-4 (which is mentioned in the YAMB guide) but it nothing comes up for me when I press control-4. Any suggestions?

berrinam

9th October 2005, 00:45

MeGUI is an all-in-one solution. Perhaps you are only using the cutdown version of MeGUI called MeGUI x264 edition. The full version can be downloaded from the first post of this thread (http://forum.doom9.org/showthread.php?t=96032) (right at the bottom of the post). Ctrl+4 opens the MP4 Muxer, but all the features can be accessed via the menus.

QuadraQ

11th October 2005, 05:25