x264 Producing Strange Artifacts in Fields of Light Color

[WhoThatBe]

I'm using x264 in MeGUI to back up all of my DVDs, utilizing MeGUI's presets to encode -- "Unrestricted 1pass Const. Quality HQ," to be precise -- at a quality setting of 18. The DVD sources are clean and original. x264 is handling fine details on the video quite impressively; however, in certain static areas of solid, light colors, heavy blocking artifacts -- like a pulsating checkerboard -- gradually develop as the scene progresses. The scene starts with great quality, but then gets progressively worse until it can draw your attention away from the scene, eventually resetting back to good quality and then repeating the pattern. I've tried heightening the deblocking strength, lowering it, enabling and disabling trellis, using more and less reference frames, but no real luck in reducing the artifacts. I jacked the quality bitrate from 18 to 16, and that made the artifacts worse, if anything. Does anyone have any idea on how to reduce the artifacts? Or is this maybe a normal occurrence for x264?

The artifacts are very clear when in motion, but can be very difficult to see on still frames; nonetheless, here are the most obvious:





MeGUI apparently uses the "Skystrife's patched build," and the command line options of x264 are as follows, if it helps: program --crf 18 --ref 5 --mixed-refs --bframes 3 --b-adapt 2 --b-pyramid --weightb --deblock -1:-1 --trellis 2 --partitions all --8x8dct --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --output "output" "input" [i]

[poisondeathray]

Post your avs script, and which x264 version (r1127 ) ?

Sometimes the AQ and psy-rd settings can cause unpredictable results, but usually on darker scenes, not bright scenes - you might try adjusting them.

Do you have a small section where this is a repeatable event?

[jagabo]

Use shorter GOPs?

[WhoThatBe]

Turns out it was the AQ after all. I disabled it, and boom -- no more of those artifacts in the sample I'm testing on. Due to the monitor I'm using at the moment, I can't tell if there's any other degradation in quality from disabling it. Strange -- I thought AQ was supposed to help with the quality of flat areas.

My AVS script is fairly simple:

ColorMatrix(hints=true, threads=0)
#deinterlace
crop( 2, 56, -2, -60)

Spline16Resize(720,320) # Spline16 (Neutral)
Undot() # Minimal Noise

Also, I'm using the 1127 build of Skystrife's -- the latest, as far as I know.

[poisondeathray]

If this is a consistent, replicable event, consider submitting a sample to the developers over at Doom9

AQ of 1.0 rarely causes problems, except on anime. I've never seen problems with what you are describing, on a bright scene - even at low bitrates.

I've seen VBV can cause blocking in dark fades, but you are not using VBV settings, and you are using crf encoding

It's too early to tell, but r1127 might be the culprit. Often things get broken with the frequency of releases. You could replace the x264.exe with an earlier revision if you wanted to do some testing/debugging

[WhoThatBe]

Actually, it seems AQ isn't quite the culprit after all . . .

So far, I've been playing these files on Zoom Player, using the latest ffdshow-tryouts as the codec; I've been testing the files with and without post-processing effects and the like. However, when I play the very same file on Media Player Classic x64 Home Cinema, using its own internal codecs, those very same files have no sign of artifacts whatsoever and are as clean as a whistle.

I'm not sure why ffdshow would be causing the problem, but oh well. At least I know I don't need to re-encode over a dozen movies. Thanks for the help.