Does x264 inherently de-noise/de-dither DVD video and reveal blocks?

[Morte66]

A while back, I bought a Dell 2405FPW LCD monitor, which is extremely bright and contrasty compared to my 8 year old 21" Iiyama CRT. On the whole it's great -- hello to 3D video -- but it sure does reveal blocking. And I've begun to notice lots of blocking with x264 encodes from DVD, mostly in deep shadow areas but also on things like foreheads in lower bitrate source.

I've tried all sorts of stuff to get rid of this. My source (playing back the avisynth script) is not blocky, but it has far more noise than the x264 encode. In particular, the problem areas that become blocky once encoded with x264 are covered in noise on the DVD. So I'm wondering if x264 is denoising the video, and incidentally removing dither to reveal blocks in the underlying MPEG2. x264 certainly seems to denoise things overall. And if I run a fairly strong denoiser on the MPEG2 (without encoding) I do see hints of blocking emerge through the mush.

So, I wonder, does x264 come with a built in denoiser that's going to de-dither the source? If so, is there anything I can do, apart from using another encoder?

My typical encodes would run from a script like:

# Set DAR in encoder to 141 : 74. The following line is for automatic signalling
global MeGUI_darx = 141
global MeGUI_dary = 74
video=DGDecode_mpeg2source("D:\MeGUI\BLANC\BLANC.d2v",info=3)
audio=nicac3source("BLANC Track 1 Français DELAY 0ms.ac3",2)
audiodub(video,audio)
ColorMatrix(hints=true)
#Not doing anything because the source is progressive
AssumeFPS(24,1,true)
SSRC(48000,False)

My encoder settings are usually something like:

--crf 22 --ref 5 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct temporal --filter -2,-2 --subme 6 --trellis 1 --analyse all --8x8dct --threads 2 --thread-input --cqmfile "C:\Program Files\x264\eqm_avc_hr.cfg" --progress --no-psnr --output "D:\MeGUI\BlancSample\blanc.mp4" "D:\MeGUI\BlancSample\blanc.avs"

Here are some things I've tried:

- I jacked the bitrate up. This had negligible effect on blocking.

- I varied the x264 deblocking options between -2-2 and +1+1. The effects were minor on the problem areas, basically the big blocky clumps got 10% smaller. The block-free areas varied as expected.

- I used Sharktooth's eqm_avc_hr custom matrix. This seems to prevent blocking on sources that never had it (like some encodes I made from uncompressed yuv), but it does nothing much for DVDs.

- I've disabled ColorMatrix(). No effect on blocking.

- I adjusted the DGIndex/Decode deblocking. It seems to introduce blocks where there were none before without deblocking the ones that that already existed, so I turned it off.

- I stopped using B frames. This helped a little, but only really scratched the surface.

- I used the blockbuster(method="noise") AviSynth filter to make x264 throw bitrate at the shadow areas. I saw the noise it added clearly when playing the avisynth script, but x264 seemed to remove it and gave me the same blocky encodes.

- I used Xvid at q4. It encoded the noise and gave me output that looked rather like the input, except the noise in the potentially-blocky areas sort of clumped and the clumps sort of crawled around.

- I use Xvid at q2. It gave output basically the same as the input, with no obvious blocking. A satisfactory encode, but rather large.

[Mug Funky]

you might want to try blindpp instead of dgdecode's internal deblocking. it's not optimal, but it's more stable (dgdecode will deblock more agressively on macroblocks with a higher quantiser, which can cause detail to flicker in and out between b-frames and p-frames).

this is a desperate measure, but you can run levels(...) on you source to clip the dark areas to pure black. you can't have visible block edges when adjacent blocks are pure black

also, check the stats x264 spits out - what percentage of blocks are being skipped?

also, direct prediction should be set to "auto" (i think that's the name of the param, but check the docs), as temporal prediction might not always be optimal. auto will use temporal and spatial where appropriate. this might just have a positive effect on the skipped blocks (which are likely to be where you're seeing blocky artefacts).

you might also want to try it without --no-fast-pskip, as that will also have an (unknown to me) effect.

but FYI, yes h.264 will remove grain, and lots of it. this may or may not be a good thing (i like to keep a bit), but h.264 does allow for film grain simulation on decoding based on side information on encoding. this will certainly hide blocking if it's there, but obviously the more elegant solution would be for the blocking to not arise at all

[Morte66]

Originally Posted by Mug Funky

you might want to try blindpp instead of dgdecode's internal deblocking. it's not optimal, but it's more stable (dgdecode will deblock more agressively on macroblocks with a higher quantiser, which can cause detail to flicker in and out between b-frames and p-frames).

OK, I'll try that when the queue clears.

this is a desperate measure, but you can run levels(...) on you source to clip the dark areas to pure black. you can't have visible block edges when adjacent blocks are pure black

If you'd seen my Seinfeld encodes, you'd know DGIndex does that for me. You get a big black blob with pulsating crinkly edges instead of an assortment of smaller black blobs with pulsating crinkly edges. At least it stays put, instead of dancing around and shouting "hey, I'm over here, ignore that guy Jerry and look at the shadows".

If I'm desperate, i.e. I can't crack it with x264, I expect I'll use Xvid at 1 or 2 movies per DVD5 to backup and give up on the media server idea. Hmm, actually, DVDShrink can be quite good at 1 movie/DVD5...

also, check the stats x264 spits out - what percentage of blocks are being skipped?

I can't make head or tail of this, but for a short clip the log says...

avis [info]: 720x576 @ 25.00 fps (481 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2 3DNow!
mp4 [info]: initial delay 2 (scale 25)
x264 [info]: slice I:2 Avg QP:19.00 size: 28962
x264 [info]: slice P:152 Avg QP:20.92 size: 5833
x264 [info]: slice B:327 Avg QP:22.64 size: 1118
x264 [info]: mb I I16..4: 40.4% 53.2% 6.3%
x264 [info]: mb P I16..4: 1.4% 1.8% 0.2% P16..4: 74.0% 5.4% 10.0% 0.0% 0.0% skip: 7.3%
x264 [info]: mb B I16..4: 0.0% 0.1% 0.0% B16..8: 18.0% 0.2% 0.4% direct: 0.1% skip:81.3%
x264 [info]: 8x8 transform intra:55.9% inter:88.4%
x264 [info]: ref P 66.1% 13.6% 12.5% 3.4% 4.4%
x264 [info]: ref B 81.7% 11.2% 4.3% 1.4% 1.4%
x264 [info]: kb/s:544.8

encoded 481 frames, 8.94 fps, 546.12 kb/s

also, direct prediction should be set to "auto" (i think that's the name of the param, but check the docs), as temporal prediction might not always be optimal. auto will use temporal and spatial where appropriate. this might just have a positive effect on the skipped blocks (which are likely to be where you're seeing blocky artefacts).

OK, I'll give that a spin.

you might also want to try it without --no-fast-pskip, as that will also have an (unknown to me) effect.

Tried it before. Enabling no-fast-pskip removes certain blocks when encoding from a clean source (yuv), especially if you're making sharp encodes (deblocking -2-2), but it seems to have no particular effect re-encoding a DVD which already has plenty of blocks.

but FYI, yes h.264 will remove grain, and lots of it.

Ah, then I guess I'm up against it.

but h.264 does allow for film grain simulation on decoding based on side information on encoding.

As best I understand it (not so well), that's a feature of the h264 standard but not something that's implemented in the x264 encoder as yet?

[Morte66]

Here's a sample, with mpeg2/x264/xvid. It's 18MB. Best watched full screen in a dark room with the contrast turned up, to experience its full glory.

[Morte66]

Ok, tried BlindPP() instead of dgdecode's deblocking. It seems to put a wide blur with graduated edges over the blocks, so I get "blobbing" instead of "blocking". I think I might prefer it, since the smooth blobs draw attention less than the sharp/jagged blocks. But it's a small thing compared to losing the noise/dither.

I tried "auto" instead of "temporal" for the prediction, and I thought it made things worse. Mostly it looked different without being better/worse, but once in a while there'd be a an obvious jump with the blocks moving around. I didn't get that in temporal mode.

I really ought to do more samples to be sure how these compare to my regular options, but so far it doesn't look like they're going to resolve the basic issue.

[shon3i]

I watched clips, and i can only say that x264 use quart smaller bitrate than XviD, and have smaler filesize.

[Morte66]

Originally Posted by shon3i

I watched clips, and i can only say that x264 use quart smaller bitrate than XviD, and have smaler filesize.

But the blocking doesn't change if you increase the x264 file size. Other things change, but not the blocking. I've been up to crf 14 with various DVDs, getting encodes that are bigger than the original MPEG2, and the block issue is essentailly the same as at crf 22. Sometimes the higher bitrate x264 encodes look worse, because they have sharper edges on the blocks.

So far as I can tell, if I find a solution to this it won't (just) be bitrate.

[shon3i]

Originally Posted by Morte66

Other things change, but not the blocking. I've been up to crf 14 with various DVDs, getting encodes that are bigger than the original MPEG2, and the block issue is essentailly the same as at crf 22

I saw that few months ago but i almost always use two pass encoding to prevent this, maybe you try to switch off deblock.

[Morte66]

Originally Posted by shon3i

I saw that few months ago but i almost always use two pass encoding to prevent this

Really? How would that help?

Do you have any suggestions for settings?

maybe you try to switch off deblock.

I'm not sure how to do that, but why do you think it would help?


I eventually managed to make encodes from yuv at crf 22 deblocking -2-2 and avoid blocks in the output (thanks to Sharktooth's CQM and no-fast-pskip). So far as I can tell, the problem isn't that x264 necessarily introduces blocking. I'm coming to think that x264's denoiser reveals blocking that was hidden by noise/dithering in the source, then the encoder reproduces those blocks as faithfully as it can at a given bitrate.

So what I'd really need is either:
- a way to turn off the de-noising and get x264 to encode the dither
- some other encoder that encodes noise (e.g. Xvid)
- some other way to properly dither the original MPEG2 blocks on playback of the final h264

[Latexxx]

These are my thoughts and it isn't sure whether everything I say is true.

X264 doesn't de-noise the source but AVC's in-loop deblocker first tries to blur and when it can't anymore it starts to block. This might appear as if it had denoised the source and revealed blocks.

So use X264 and use higher bitrate and/or two-pass encoding. 2-pass encoding gives hard scenes more bits than easier scenes so you should end up with less blocks as there is more bits to be used in hard scenes.

Here is a small example.
You are doing 1000 kbps encoding. When you do it as cbr, every second gets 1000 kilobits. When using 2-pass, easier (less high frequency content = details) get something likee 500 kbps and harder-to-code parts get 1500 kbps. NB this is an over simplification.

There should be an easy way to determine where the blocks originate from. Take your mpeg-2 source and resize it before coding to avc. If blocks are 16 pixels wide then they originate from avc but if they are some other size then they are from your mpeg-2 source. That is because mpeg-2 blocks are 16x16 pixels as are avc's block usually.

[Morte66]

Originally Posted by Latexxx

So use X264 and use higher bitrate and/or two-pass encoding. 2-pass encoding gives hard scenes more bits than easier scenes so you should end up with less blocks as there is more bits to be used in hard scenes.

I thought crf was meant to do that, by a different route. But I'll certainly give it a spin.

There should be an easy way to determine where the blocks originate from. Take your mpeg-2 source and resize it before coding to avc. If blocks are 16 pixels wide then they originate from avc but if they are some other size then they are from your mpeg-2 source. That is because mpeg-2 blocks are 16x16 pixels as are avc's block usually.

OK, will do. Thanks for the idea.

[Mug Funky]

Originally Posted by x264 stats

mb B I16..4: 0.0% 0.1% 0.0% B16..8: 18.0% 0.2% 0.4% direct: 0.1% skip:81.3%

that seems a high number of skipped blocks... my low bitrate stuff tends to be around the 70% mark (and seems to skip more on p-frames). for a grainy source that seems a bit much. hmmm. have you tried it without any CQM? sharktooth's should be fine, but it's all i can think of for now (the matrix used influences bitrate but not RC decisions like block skipping).

[smok3]

or maybe try callibrating the monitor first..., i have a dell thingy as well, and there was no way to set this thing properly (1905FP)

[*.mp4 guy]

The blocks you are seeing in low contrast areas are cause by quantisization, not by skipped blocks (skipped blocks create a different kind of blocking, it looks a lot different) the easiest solution is to use a cqm that doesn't drop as many frequencies.

If you wan't to try a cqm, this one should work well, though you should change Bframe predict mode to none to stop X264 from behaving badly.

Originally Posted by Mug Funky

(the matrix used influences bitrate but not RC decisions like block skipping).

Thats actually not true, the matrix does effect RD decisions, usually its not a problem, but sometimes X264 can get a bit wierd about matrices.

[juerginst]

Any other recommendations for this matrix? Low, mid or high bitrates?

[*.mp4 guy]

Mid-low, to mid-high, about the same amount of ringing as the standard matrix, a lot less blocking in low contrast areas. Better preservation of faint details, a bit worse preservation of prominent details, more texture-noise artifacts and smearing then the standard matrix.

[Revgen]

Originally Posted by Morte66

A while back, I bought a Dell 2405FPW LCD monitor, which is extremely bright and contrasty compared to my 8 year old 21" Iiyama CRT. On the whole it's great -- hello to 3D video -- but it sure does reveal blocking. And I've begun to notice lots of blocking with x264 encodes from DVD, mostly in deep shadow areas but also on things like foreheads in lower bitrate source.

I have the same monitor and the same experience. LCD's are so bright that blocks that you never saw on a CRT are revealed on LCD's. CRT's are far more superior in terms of image quality, yet they are too expensive now that manufacturers have switched to LCD's. Try working with the brightness and contrast levels as much as possible to improve it.

The other thing to do is to use better denoisers than you did in the past.

[CAFxX]

On my Vaio laptop I could spot those blocks even on good DVDs.
The only way you can get rid of these blocks is by calibrating the monitor. Lower the gamma and brightness, ensure you have the proper profile loaded in the color manager.
Eventually use an utility such as Adobe Gamma.

[Morte66]

OK, replying to most of this...

@Shon31/Latexxx re 2-pass vs crf:

A 2-pass encode at the same bitrate as the crf encode (which varies the bitrate as it goes along to hit a quality goal) looks essentially the same. Doubling or quadrupling the bitrate made only minor differences to the blocky areas, maybe the big groups of blocks got 10% smaller.


@Latexx re resized encode:

I did a resize to 1440x1152 before encoding, then compared it to a 720x576 encode resized after encoding. The block structure is still predominantly the same, which indicates that the blocks are predominantly in the MPEG2. The result does seem a bit less crinkly around the edges though, which suggests that x264 is adding a little mischief of its own, on a smaller scale.


@MugFunky re not using any CQM:

That's what I was doing at the start. Sharktooth's CQM has helped a little with blocking (it is, as I understand it, specifically an anti-blocking matrix). I do do the occasional "control check" with the x264 default matrix, and it's not a lot different.


@Smok3/Revgen/CAFxX re monitor cal:

My monitor is very carefully calibrated -- I'm a photographer and I use it for proofing. Never mind Adobe Gamma, I own a hardware calibrator that measures test patterns on screen. I see what you're saying: by using the full luminosity range of the monitor to get a punchy and revealing picture, I'm revealing flaws in that picture. Sure, I can squash the picture to hide the flaws (I've tried this), but then I hide the good stuff too. The key point here is that the blocking did not bother me on the DVD because it was hidden by noise/dither (unobtrusive at a suitable viewing distance). But the blocking does becomes a problem on the x264 encode using the same monitor setup, whether x264 reveals it or creates it.


Thanks for all the help and suggestions, everybody.


@*.mp4 guy

You're next, when the queue clears.

[GodofaGap]

If you ever find a better solution than adjusting levels, please let me know. I've been annoyed by this for quite a while but never found anything that solves it (yes, I tried CQMs, but perhaps not the right ones...)