QComp for Intraframe MB Equivalent?

[TheBashar]

Does anybody know if there is an x264 setting or tweak that can be applied to give more weight to easily compressed MBs at the expense of harder to compress MBs in the same frame?

I have been trying to determine a good bitrate for a multi-pass encode of my test clip. It's very hard because the main detail of the video looks great down even at 1200. The backgrounds however look bad to me in places at 1600. When I say they look bad, I mean there are blocks on low contrast (smudgy gradient) areas. The blocks wouldn't be so noticeable except when the camera moves a little, the blocks cant decide what color to be and they sort of flicker as they change color. Also, camera pans look poor because these same blocks tend to lag the pan a bit which really stands out.

Is there some some way I can adjust the intraframe balance to take some of the excess bitrate from the high-detail areas and give it to these less detailed areas? I know that sounds counter-intuitive, but.. well... that's what's needed.

Thanks!

[Shinigami-Sama]

inloop deblocking and AQ would seem like it would do the trick
but not to upto date on AVC

[TheBashar]

inloop deblocking and AQ would seem like it would do the trick
but not to upto date on AVC

I was going to reply that I had tried increasing the beblocking with little success. Increasing deblocking means softening of the image. And the problem here is that too much of the detail is being lost in these low detail areas. But thanks for the post because it wasn't until I started this reply that the thought hit me to try reducing the inloop deblocking. Let's see what effect that has.

[TheBashar]

Still no luck in my testing. I think the issue is simply that x264 is not tuned to address this kind of content well. For instance, I have a white (digital) snow falling on pinkish background scene. The snow effect is adequate in the source but gets softened into a whitish macroblock falling scene in the encode. Foreground details look fine ~1400 but at 2500 the snow still looks macroblocky. I ran an encode at around 10,000 and the snow finally looked decent.

I don't know exactly why, but x264 seems to throw away too much information (soften) in low contrast areas. These low contrast areas then turn into something like color averaged blocks. :(

[DeathTheSheep]

Hm... yes, I've noticed this too. Dark or low-contrast scenes do seem to lack much quality, even at high bitrates. Do you think you might be able to upload about 10MB of the source?

OT: This was a problem with VP7 too, but I don't know the status on that.

[TheBashar]

Do you think you might be able to upload about 10MB of the source?

I'm immersed in testing out the new TIVTC v0.9.10.2 release so it will be a little while before I can isolate a good dark / low contrast background example. I have two in my mind. One demonstrates color changing macro blocks. The other demonstrates a pretty outrageous smearing (camera pans, but details lag).

In the meantime, you can get a sample of general softening / smearing problems I've been having in the post I made to the x264 development thread: http://forum.doom9.org/showthread.php?p=710087#post710087

Note, as mentioned after my inital post: the source file is the source of the encode problem examples. It has been post-processed so it is not a virgin source.

[DeathTheSheep]

The blocks wouldn't be so noticeable except when the camera moves a little, the blocks cant decide what color to be and they sort of flicker as they change color. Also, camera pans look poor because these same blocks tend to lag the pan a bit which really stands out.


Ah, I just noticed this. This is particularly troubling in anime panning ("camera" moves very slowly and steadily across the scene). The blocks frequently stay put (in low contrast areas) and then jump ahead and flicker. It is kinda annoying, even if you set the "smear factor" (in-loop deblocking ;)) to max.

But overall, this doesn't appear to be all to much of a problem... x264 seems to excel at very low bitrates but get steadily less powerful at about 1.6mbps, or so it seems-- It is at these crystal-clear-quality bitrates when wierd motion arifacts, contrast artifacts, block-jumping artifacts, etc stand out most obviously to the viewer.

I haven't been following this topic much; how is it going (in a nutshell)?

[TheBashar]

I haven't been following this topic much; how is it going (in a nutshell)?

Sadly, no progress. Someone (maybe you) recommended using zones to pump the bitrate up in problem areas. I hate that solution because I have to encode, view concentrating hard, note frame ranges, fill in a bunch of zones, and then re-encode. :(

I have these artifacts (exactly as you described) happen a lot with my tv show DVDs. Dark walls with a slow pan often get munged. I personally think its a bug in x264, but if it can't be addressed by tweaking a CQM, I can't imagine how it could get fixed. My understanding is that there is no rate control mechanism where x264 could analyze how a frame (or better a MB) looks compared to the original, and throw more bitrate at it as necessary.

My understanding (flawed I'm sure) is that it assumes a Q17 for one MB is the same quality reduction as a Q17 against another MB. But that's just not true as seen in these high contrast vs low contrast cases. That's why I think ultimately a CQM has to be the solution. Of course, I have no idea how CQMs work so it could be that they only effect color ranges and have no concept of contrast.

Oops, I seem to have missed the in a nutshell part. ;)

[akupenguin]

CQMs only differentiate between frequencies. They have no idea about color or constrast.