No-fast-pskip inferior to Adaptive Quants?

[Mentar]

I'd like to ask the gurus for help in one issue, because I can't seem to get it done right.

The task is encoding a clean anime DVD source with alot of dark-grey spots. Bitrate is high (2000+), source video is very stable.

My problem: The latest builds ever since the Adaptive Quants were removed again _always_ exhibit the old problems, with or without no-fast-pskip: Nasty moving/morphing blocks in dark areas, around lighter pixels. Where AQ nicely dithered these places and thus "hid" them from the view, the dreaded old blocks are back and looking really poor. (I heard of the same issue from enough other people to skip posting screenshots yet, but if they are desired, I can provide them)

The results have been so consistent that I've recently downgraded to build 375 again, and all the problems are gone again.

So my questions:

1) Is there anything else I need to do to recreate the excellent stable dithering of AQ in dark places, with the new builds?

2) If not, why was AQ removed again?

Any hints would be very much appreciated.

EDIT: I forgot to mention - for the newest build I was using the 3P-Slowest preset.

[bond]

provide a video source for recreating this and screenshots plz

[OvejaNegra]

MMMM the uggly blocks, i have the same problem with ocean´s eleven.
¿This is normal? i´m encoding with a fixed q=22:
"x264.exe" --qp 22 --ref 5 --mixed-refs --no-fast-pskip --bframes 3 --b-rdo --weightb --nf --subme 7 --analyse all --8x8dct --me esa --merange 10 --progress --no-psnr --output "" ""

Why this blocks?

sorry for my bad english!!!!

[Doom9]

dare I ask why you disabled the in-loop filter and use an insane motion estimation setting?

[DeathTheSheep]

OvejaNegra:
Um...interesting. Yes, that's the word: interesting.
If your encodes have blocks, try turning on deblocking
It just might help!

And as for that ME setting... How about using --me umh --merange 16
It's faster and probably a... better... choice (though I hate to use that word!).

[ChronoCross]

ME range should be between 16 and 32. I think Sirber had used a me range of 64 before but akupenguin had talked about a major slowdown in the highest 2 --me settings when 64 is used.

[Romario]

Originally Posted by Mentar

The task is encoding a clean anime DVD source with alot of dark-grey spots. Bitrate is high (2000+), source video is very stable.

My problem: The latest builds ever since the Adaptive Quants were removed again _always_ exhibit the old problems, with or without no-fast-pskip: Nasty moving/morphing blocks in dark areas, around lighter pixels. Where AQ nicely dithered these places and thus "hid" them from the view, the dreaded old blocks are back and looking really poor. (I heard of the same issue from enough other people to skip posting screenshots yet, but if they are desired, I can provide them)

The results have been so consistent that I've recently downgraded to build 375 again, and all the problems are gone again.

Yeah man, you are right. Same happens to me, one music spot, Britney Spears. I lost the sourse somehow, so I can't provide pictures, but I am hope that Sharktooth will again include Adaptive Quantization in his new builds.

I use no-fast-no-pskip, and it's worthless, nothing happened. Same ugly blocks stayed.

My settings are: 5 ref frames, 2 B-frames, Mixed frames off, Mode:Automated 2pass, bitrate 800, Keyframe interval 200, Pyramid and Adaptive for B-Frames is on, Deblock Filter on, Alpha Deblocking 0, Beta Deblocking 0, CABAC on, Subme 6, Weighted Prediction on, Chroma ME on, Macroblock options: ALL, AVC Profiles is Main profile, AVC Level: Unrestricted, RDO for B-Frames is on, No Fast P-Skip is on, Bidirectional ME is on, Trellis Quantization off, B-Frame bias is 0, B-Frame mode is Temporal, ME Algo is Hexagon, ME Range 16.

So, I provided ALL my settings, so I hope that someone will rewrite new Adaptive Quantization patch and re-include it in the future x264 builds.

Thank you, and I am waiting for good answer

[bond]

if you wanna get rid of blocks, use a higher bitrate or higher deblocking values

[Romario]

Well, I set bitrate to 1200 and nothing. And I don't won't anymore to increase bitrate.

Would I set deblocking to -2 or +2, what is your suggestion?

[bond]

+6,+6 will remove all blocks

[OvejaNegra]

Well:
I always encode with a fixed quantizer, i don´t care the final size of the video.
The in-loop filter sometimes eat detail when i encode real life footage.
The Insane motion estimation gives me smaller videos (i don´t care the compression time), "me esa --merange 10" works very well for me.
BTW.... lowering the quantizer doesn´t dissapears the blocks.

If you want an interesting source for testing try this:
http://www.microsoft.com/windows/win...tShowcase.aspx
I like robotica (of course this is not a normal source but is good for testing)

[Selur]

@bond: Am I mixing something up or shouldn't it be +6(strength), -6(threshold) be 'better'. Lowering the threshold when to deblock and lifting the how strong to deblock ?

Cu Selur

[foxyshadis]

+6,-6 would give you very blocky video mixed up with a few totally blurred out squares that looks even worse than ffdshow with h.264 PP on. (Which looks like Snow or jpeg2000 at too low bitrates.)

The first is how much blur, the second is how many blocks it acts on. If they're way out of sync, like +2,-3, you'll start noticing how unpleasantly the deblocked and not deblocked areas mesh.

[Selur]

Is this right?

I kind of thought that there's a standard value x, and if a macroblock is encoded at a quantizer greater or equal than x, deblocking is applied with strength y. So beta(threshold) would modify x and alpha(strength) would modify y.

Would be nice is someone could shed some light on this matter.

Cu Selur

Ps.: sorry, for 'carpering' the thread.

[Manao]

Deblocking strength is controled by values called alpha & beta. These values are computed for each macroblock according to the quantizer of this macroblock, the quantizer of its neighbour, and the offset you set ( the famous value that range from -6 to +6 ).

Here are the tables for alpha & beta, indexed by 'quantizer + offset' :

alpha : 

     0,  0,  0,  0,  0,  0,  0,  0,  0,  0,
     0,  0,  0,  0,  0,  0,  4,  4,  5,  6,
     7,  8,  9, 10, 12, 13, 15, 17, 20, 22,
    25, 28, 32, 36, 40, 45, 50, 56, 63, 71,
    80, 90,101,113,127,144,162,182,203,226,
    255, 255

beta :

     0,  0,  0,  0,  0,  0,  0,  0,  0,  0,
     0,  0,  0,  0,  0,  0,  2,  2,  2,  3,
     3,  3,  3,  4,  4,  4,  6,  6,  7,  7,
     8,  8,  9,  9, 10, 10, 11, 11, 12, 12,
    13, 13, 14, 14, 15, 15, 16, 16, 17, 17,
    18, 18

The higher these values, the stronger the deblocking. When one of these is null, there's no deblocking on the macroblock.

As you can see, when 'quantizer + offset <= 15', both alpha and beta are null, so no deblocking is applied.

Alpha is used to determine whether the frontier is blocky or if it's actually a detail. It works like a threshold. Beta also works as a threshold, but is used to insure that on both side of the frontier, the picture is homogenous enough ( once again, to separate detail from blockiness ).

Once you've decided whether or not to filter the frontier, alpha is used to decide the strength ( in fact, the maximal allowed modification to a pixel ). beta can slightly modify this strength, is the macroblock is flat enough.

So in the end, foxyshadis' description is a bit too simple. Both offsets decide which blocks, and the first one influences the bluriness the most.

[slavickas]

/|\
.|
that post should be bookmarked/added to stickies

[Selur]

thx for clearing that Manao

[OvejaNegra]

i think this may be interesting:
i have the build (release) 396a and the dark areas blocks are gone (i´m not using loop filter)

a bug????

BTW the explanation of the deblocking is VERY useful...

Thanks!!