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

[Mug Funky]

h.264 supports "film grain simulation" which does what you ask.

x264 doesn't support it, and most (all?) decoders don't. but it's likely to be supported in the future, when it becomes less fashionable to overfilter encodes.

[check]

troll? It must be.
In any case, the nitpicker within me wants to point out that the feature is actually named "film grain modelling" (at least, that's what I've seen it referred to as).

[bananacreamandpeca]

Am trying a few things of my own to reduce those nasty looking things in the output.

I was wondering. If turning deblocking to off. Would that make things worse when trying to reduce those blocks?
Some say I should turn deblocking up
Some say to lower the value to a negative value

[Morte66]

I am just very lucky that i find grain and noise as a great thing. Some people hate it !

You certainly are lucky, I don't like noise much.

[Morte66]

Am trying a few things of my own to reduce those nasty looking things in the output.

I was wondering. If turning deblocking to off. Would that make things worse when trying to reduce those blocks?
Some say I should turn deblocking up

Easy to try.

Some say to lower the value to a negative value

For what it's worth, I think of the Deblocking settings in x264 as a sharpness control. They have a strong effect on sharpness, -2-2 looks like Xvid 1.2 and +0+0 looks like DivX3 (IMVHO, YMMV, taste is personal, etc). Whilst they do also effect blocking overall, it's minor compared to the blocks on the DVD you're encoding from and it has a minor effect on smooth/dark areas compared to a CQM.

If I'm encoding from a clean uncompressed source without any blocking (as I have done once or twice to experiment), x264 deblocking matters a lot more.

[Single]

I think all people who tries to do a details looks at coding results mast do a monitor calibration at first of all. Most of LCD monitors has a very very bad linearity compared to a cheap CRT. Calibration is a gamma at first than britness and contrast.

[bananacreamandpeca]

Can 'enabling CABAC' cause these blocks in x264?
No one ever mentions it. It says it can decrease bitrate with no Q. loss.
So how does it do that?

[akupenguin]

how it does that (http://en.wikipedia.org/wiki/Arithmetic_coding)

[Sharktooth]

Can 'enabling CABAC' cause these blocks in x264?
No one ever mentions it. It says it can decrease bitrate with no Q. loss.
So how does it do that?
Does zipping a file decrease its size without loosing data? ... (answer: yes)
CABAC does the same with the bitstream (well, cabac is a bit more complex than the zip/deflate algo though...) so it doesnt affect image quality at all.

[shon3i]

Yes, but zip is lossless process, and nobody can confirm that is CABAC 100% lossless.

[Sergey A. Sablin]

Yes, but zip is lossless process, and nobody can confirm that is CABAC 100% lossless.

I do.

[Manao]

...

CABAC is lossless. So is CAVLC. The lossy stage in h264/avc is the DCT / quantization stage.

[shon3i]

I do.
Ok, then, we clear that. Thanks.

What about PCM coding, it is usefull for something, and it is lossles?

[Manao]

It's not lossless ( 0 or 255 ( I don't remember which one ) ) can't be coded.

It's largely useless. It allows a resetting of the cabac contexts, so it's mostly an error resilience tool. It costs a lot of bitrate : a 64x64@25 fps video completely in PCM has a bitrate of 1.25 mbps.

[Sharktooth]

@Manao: is it possible to modify the bitstream data to maximize the CABAC efficiency but keeping the h.264 decoded data very similar to the original result?

[akupenguin]

It's not lossless ( 0 or 255 ( I don't remember which one ) ) can't be coded. 0 can't be coded in PCM in main profile (I'm gessing so that the decoder can just use the next 384 bytes instead of running startcode emulation prevention?), but it is allowed in high profile. Otherwise you couldn't use PCM in the only case where it makes sense: lossless compression. (PCM is not compressed, but by Pidgeonhole Principle some macroblocks would be even bigger if you try to compress them losslessly with inter/intra prediction + cabac.)

is it possible to modify the bitstream data to maximize the CABAC efficiency but keeping the h.264 decoded data very similar to the original result?
That's called rate distortion optimization.

[Sharktooth]

thanks.

[ToS_Maverick]

@morte66: did you try AQ?

i know it's been a while since this topic started. i, like morte, always had problems with big ugly blocks. i recently tried out AQ and got great results, you can see them here (http://forum.doom9.org/showthread.php?p=996829#post996829). as i'm really excited about it, i just wanted to mention it here ;)

for slight blocking i'd recommend --aq-strength 0.3 to 0.6, if you got severe blocking, 0.9 to 1.2 works great. be warned that the bitrate in the critical parts of the video will increase dramatically!