MeGUI and Adaptive Q parms: Any chance ?

[Atak_Snajpera]

If he can upload a clip of the AQ and non-AQ encode, I can analyze it with Elecard Streameye Tools and give a nice unbiased result

http://forum.doom9.org/showthread.php?p=1043895#post1043895

[foxyshadis]

There's nothing related to dark or blue in that patch. Dark and blue areas are just the most common "flat" textures, but it'll apply to light grey (fog) as well as any color of shallow gradient. (In fact it could also apply on any texture that uses very few bits on just a few of high frequencies, rather than low freq, but that's so rare it's not important. I used to see it happen more often with MPEG-1, and still do with JPEG, but it was probably a bad encoder artifact.)

[Dark Shikari]

http://forum.doom9.org/showthread.php?p=1043895#post1043895
Done, here's some images of a B-frame with Elecard StreamEye (I love this software!)

Without AQ (Partition sizes):
http://i9.tinypic.com/5yv1d9x.png

With AQ (Partition sizes):
http://i14.tinypic.com/6c450mh.png

Now this is interesting: the non-AQ encode has smaller partitions! But we're not done yet.

Without AQ (Bits per macroblock):
http://i2.tinypic.com/4thowop.png

With AQ (Bits per macroblock):
http://i10.tinypic.com/6apron5.png

Well that looks pretty obvious right there. But if that isn't good enough:

Without AQ (Quantizer):
http://i2.tinypic.com/63kf0vo.png

With AQ (Quantizer):
http://i5.tinypic.com/66nmckh.png

Yes, AQ is being activated :p

[Sharktooth]

There's nothing related to dark or blue in that patch. Dark and blue areas are just the most common "flat" textures, but it'll apply to light grey (fog) as well as any color of shallow gradient. (In fact it could also apply on any texture that uses very few bits on just a few of high frequencies, rather than low freq, but that's so rare it's not important. I used to see it happen more often with MPEG-1, and still do with JPEG, but it was probably a bad encoder artifact.)
it counts blue pixels and red pixels for a reason... in bright non blue places and when there's too much red, there wont be any AQ.
again... look at the code FFS!
+void x264_adaptive_quant( x264_t *h, x264_mb_analysis_t *a )
+{
+ DECLARE_ALIGNED( static uint8_t, zero[FDEC_STRIDE*8], 16 );
+
+ int16_t dct[8][8];
+ int total = 0;
+ int i_qp = h->mb.i_qp, i_qp_adj;
+ float fc;
+
+ if( i_qp <= 10 ) /* AQ is probably not needed at such low QP */
+ return;
+
+ if( h->pixf.sad[PIXEL_16x16](h->mb.pic.p_fenc[0], FENC_STRIDE, zero, 16) > 64*16*16 )
+ { /* light places */
+ if( h->pixf.count_8x8(h->mb.pic.p_fenc[1], FENC_STRIDE, 0x81818181) < 40 )
+ /* not enough "blue" pixels */
+ return;
+
+ if( h->pixf.count_8x8(h->mb.pic.p_fenc[2], FENC_STRIDE, 0x87878787) > 24 )
+ /* too many "red" pixels */
+ return;
+ }
+
+ h->dctf.sub8x8_dct8( dct, h->mb.pic.p_fenc[0], zero );
+ x264_add_dctq( dct, &total );
+ h->dctf.sub8x8_dct8( dct, h->mb.pic.p_fenc[0] + 8, zero );
+ x264_add_dctq( dct, &total );
+ h->dctf.sub8x8_dct8( dct, h->mb.pic.p_fenc[0] + 8*FENC_STRIDE, zero );
+ x264_add_dctq( dct, &total );
+ h->dctf.sub8x8_dct8( dct, h->mb.pic.p_fenc[0] + 8*FENC_STRIDE + 8, zero );
+ x264_add_dctq( dct, &total );
+
+ if( total == 0 ) /* sum is 0, nothing to do */
+ return;
+
+ x264_cpu_restore( h->param.cpu );
+
+ fc = (float)expf(-5e-13 * total * total);
+
+ //printf("AQ: %d %.3f\n", total, fc);
+ /* the function is chosen such that it stays close to 0 in almost all
+ * range of 0..1, and rapidly goes up to 1 near 1.0 */
+ i_qp_adj = (int)(i_qp * h->param.analyse.f_aq_strength / pow(2 - fc, h->param.analyse.f_aq_sensitivity));
+
+ /* don't adjust by more than this amount */
+ i_qp_adj = X264_MIN(i_qp_adj, i_qp/2);
+
+ h->mb.i_qp = a->i_qp = i_qp - i_qp_adj;
+ h->mb.i_chroma_qp = i_chroma_qp_table[x264_clip3( h->mb.i_qp + h->pps->i_chroma_qp_index_offset, 0, 51 )];
+}
so, no, it wont apply on light gray fog!

@dark shikari: the sky is blue there... and if you look at the pics you posted AQ is ONLY activated on blue or dark areas...

[Terranigma]

I have to take Sharktooth's and Zero1's side here.
I love this part: BIG FAT WARNING:

This disclaimer is as much to cover my ass, as it is to ensure you are not being mis-informed.
Also, about aq-sensitivity

--aq-sensitivity
This switch is to be used in conjunction with --aq-strength, and will not work if --aq-strength is set to 0.0, or not specified (since it is disabled by default). This controls the "flatness" threshold at which to apply AQ (Adaptive Quantisation). Setting it to 5 will apply AQ to almost all blocks, and setting it to 22 will apply it only to flat blocks. A flat block would be described as an area of solid colour or little detail.

[Sharktooth]

My preferred way to fix blockiness is using a custom quantization matrix. a very low coefficient (lower than 8) for low frequencies will ensure a better quantization for blocky areas.
with h.264 you can also trim luma and chroma matrices...

[Atak_Snajpera]

Dark Shikari could you do the same but with frame (for example frame no. 304) where I see blocks if I don't use AQ

[Dark Shikari]

Dark Shikari could you do the same but with frame (for example frame no. 304) where I see blocks if I don't use AQ
Done, Display Frame 304.

x264, no AQ, Macroblock Type:
http://i3.tinypic.com/33bk9kz.png

x264, AQ, Macroblock Type:
http://i13.tinypic.com/67gwrxv.png

Notice the vastly lower number of skipped blocks (yellow) in the sky when AQ is used.

x264, no AQ, Motion Vectors:
http://i18.tinypic.com/4p4avqp.png

x264, AQ, Motion Vectors
http://i5.tinypic.com/6cpj6n5.png

The newly non-skipped blocks introduced in AQ not surprisingly carry a lot of motion vectors with them. Quite long ones, sometimes, in fact.

x264, no AQ, Quantizer + Partitions:
http://i16.tinypic.com/6b0o09e.png

x264, AQ, Quantizer + Partitions:
http://i2.tinypic.com/4uudshe.png

Without AQ, the entire sky has basically no partitions at all. AQ adds some partitions and lowers the quantizer a lot.

x264, no AQ, Bits per Macroblock:
http://i4.tinypic.com/4porrr6.png

x264, AQ, Bits per Macroblock:
http://i18.tinypic.com/6f7v281.png

Should be obvious.

[Sharktooth]

it's no surprise at this point since the sky is indeed bright blue...
however AQ is producing a lot of MVs in the sky and those require even more bits.
now let's see if we can get a better picture without AQ just using a custom matrix...
please encode the same clip using EQM AVC-HR and lets see the results...
however why no one asked aku the reason AQ isnt in the x264 SVN?
im curious to hear his answer...
also, if you cant read the code, ask him what AQ exactly does...

[Atak_Snajpera]

Source is here
http://www.dvinfo.net/conf/showthread.php?t=77116
3. Tripod James & me Triple auto focus Size: 51.9Mb

right click and select Save Link As

I only need to know why XviD has smaller blocks than newer technology. Is this a part of H.264 standard?

[deets]

i did indeed try your custom matrix last night on a clip and its very good :)

one question though, how are encodes with custom matrices handled on non PC devices, will they play fine on PS3, xbox and PSP for example?

[Terranigma]

I know sharktooth doesn't recommend the prestige matrix(:p), but you should give it a try as well to see how it fares against blocking.

[Atak_Snajpera]

eqm_avc_hr.cfg
http://img262.imageshack.us/img262/1064/eqmavchrra7.th.png (http://img262.imageshack.us/my.php?image=eqmavchrra7.png)

Gamma 0.4
http://img510.imageshack.us/img510/1452/eqmavchrgamma04dc1.th.png (http://img510.imageshack.us/my.php?image=eqmavchrgamma04dc1.png)

[Terranigma]

Atak, can you try with the Prestige CQM (http://forum.doom9.org/showpost.php?p=989214&postcount=2) matrix?

[Sharktooth]

my opinion is it looks just better than the non-AQ pic...
better coefficients distribution may completely "fix" the blockiness.
ill work on a new anti-blocking matrix ASAP.

@deets: if the device fully supports the AVC high profile, then there will be no problems

[Atak_Snajpera]

Prestige
http://img126.imageshack.us/img126/6744/prestigecg6.th.png (http://img126.imageshack.us/my.php?image=prestigecg6.png)

gamma 0.4
http://img252.imageshack.us/img252/2865/prestigegamma04ua3.th.png (http://img252.imageshack.us/my.php?image=prestigegamma04ua3.png)

my opinion is it looks just better than the non-AQ pic...
Image quality is similar to --aq-strength 0.5 --aq-sensitivity 5 but custom matrixes work only with high profile. AQ works with all profiles.

[Terranigma]

Prestige looks good and this is without aq ?
I wonder how it'd look with adaptive quantization. Maybe it'd block more since it may conflict with the matrix's decision.

[Sharktooth]

noise and stuff like that is high frequency, and since the matrix is "supposed" to be tuned to preserve high frequencies, it is quite useless in this case where low frequencies are poorly quantized...
infact the prestige encode is as blocky as the original... however i still cant see blocks at the correct brightness... (FYI my monitor is this: http://www.asus.com/products.aspx?l1=10&l2=89&l3=356&l4=0&model=1382&modelmenu=1)
about AQ, matrices and profiles, high profile (FRExt) was explicitly made to reach a better visual quality and if a device isnt compatible with high profile then its not aimed to produce a high quality playback.
iPods & co. are a clear example of low quality devices. the high profile doesnt make almost any difference so they support lower specs...

[Terranigma]

better coefficients distribution may completely "fix" the blockiness.
ill work on a new anti-blocking matrix ASAP.
I can't wait.:D How long does it usually take you to create a custom matrix?

[Sharktooth]

creating? 2 minutes... tuning? several days...

EDIT: my current idea is to crate a "ripple-shaped" coefficients distribution for luma, having the lower ones on the corners to preserve both low and high frequencies (flat areas and noise/grain), sacrificing some apparently random intermediate ones a bit (in pure HVS style).
thinking about it... the idea may also work for MPEG-4 ASP too...

[Atak_Snajpera]

Prestige looks good and this is without aq ?
Sharktooth's matrix looks better

[Sharktooth]

time to reboot... if everything will work (usually an "emerge -uavDN world" is a real pain in the a$$... but the true pain comes when emerging system...) i will try render my idea into a matrix for the weekend...

[Sharktooth]

luckily the linux box restarted without major problems so...
this is more or less the idea for ASP:
8 8 9 9 9 9 8 8
8 9 10 10 10 10 9 8
9 10 11 12 12 11 10 9
9 10 12 11 11 12 10 9
9 10 12 11 11 12 10 9
9 10 11 12 12 11 10 9
8 9 10 10 10 10 9 8
8 8 9 9 9 9 8 8

16 16 17 17 17 17 16 16
16 17 18 18 18 18 17 16
17 18 19 20 20 19 18 17
17 18 20 19 19 20 18 17
17 18 20 19 19 20 18 17
17 18 19 20 20 19 18 17
16 17 18 18 18 18 17 16
16 16 17 17 17 17 16 16
http://img253.imageshack.us/img253/803/ripplematrixbg7.th.png (http://img253.imageshack.us/my.php?image=ripplematrixbg7.png)

***WARNING*** - this stuff is completely untested!

[Sharktooth]

can you please re-encode the clip with xvid and the previously posted matrix and the one that follows then post the usual screenshots?
8 8 9 9 9 9 8 8
8 9 10 10 10 10 9 8
9 10 11 12 12 11 10 9
9 10 12 11 11 12 10 9
9 10 12 11 11 12 10 9
9 10 11 12 12 11 10 9
8 9 10 10 10 10 9 8
8 8 9 9 9 9 8 8

8 8 9 9 9 9 8 8
8 9 10 10 10 10 9 8
9 10 11 12 12 11 10 9
9 10 12 11 11 12 10 9
9 10 12 11 11 12 10 9
9 10 11 12 12 11 10 9
8 9 10 10 10 10 9 8
8 8 9 9 9 9 8 8

[fields_g]

If you want some fun trying to kill these blocks off, I'd recommend the new Disney production logo sequence that was unveiled with "Pirates: Dead Man's Chest" (still shot (http://upload.wikimedia.org/wikipedia/en/d/dd/Waltdisneypictureslogo.png)). It is on "Bridge to Terabinthia" also. (Any other sources guys?)

Animated CGI footage with dark, blue, motion, and fine details everywhere! No need to be playing with gamma and tilting your lcd screens and adjusting brightness/contrast. The problems are so evident. It will give AQ/CQM/dead zone settings a run for the money!

[Dark Shikari]

If you want some fun trying to kill these blocks off, I'd recommend the new Disney production logo sequence that was unveiled with "Pirates: Dead Man's Chest" (still shot (http://upload.wikimedia.org/wikipedia/en/d/dd/Waltdisneypictureslogo.png)). I think it is on "Bridge to Terabinthia" also. I'll check tonight. (Any other sources guys?)

Animated CGI footage with dark, blue, motion, and fine details everywhere! It will give AQ/CQM/dead zone settings a run for the money!
Perhaps this is another chance for the old idea of mine... instead of AQ, here's what you do:

Encoding a macroblock:
1. Run a blocking metric on the source that measures how "blocky" that macroblock already is.
2. Do the motion estimation, etc, etc.
3. Encode the block at the normal quantizer.
4. Run the blocking metric again. If the blocking metric is much higher than it was before, re-encode the block at higher and higher quantizer until it gets within a certain tolerance of the original value.

Suddenly, no more blocks... without screwing up intra/inter prediction with a broken matrix like Prestige, and without adding extra bits where they aren't needed like AQ sometimes does.

[Sharktooth]

that would mean a major slowdown. during 4) a sort of prediction of the needed QP variance to reencode the block would waste less time.

[Dark Shikari]

that would mean a major slowdown. during 4) a sort of prediction of the needed QP variance to reencode the block would waste less time.It wouldn't be a horrible slowdown, as most of the time is already spent (motion estimation, etc).

A simple prediction heuristic would help though.

[Sharktooth]

yep, expecially if you have a lookup table with metric ranges and quantizer variations based on empirical tests or a simple formula for calculating quant variation in function of metric test variation (also empirical).
an even better solution would be:
1) Run a blocking metric on the source that measures how "blocky" that macroblock already is.
2) if metric indicates blocking then apply a debanding/deblocking filter using a dithering method and proceed with normal encoding else
3) encode at normal quant and run the blocking metric again.
4) If the blocking metric is much higher than it was before, apply a debanding/deblocking filter using a dithering method and proceed re-encoding the block.

This method will even improve visual quality if source has already blocking artifacts

[Dark Shikari]

yep, expecially if you have a lookup table with metric ranges and quantizer variations based on empirical tests or a simple formula for calculating quant variation in function of metric test variation (also empirical).
an even better solution would be:
1) Run a blocking metric on the source that measures how "blocky" that macroblock already is.
2) if metric indicates blocking then apply a debanding/deblocking filter using a dithering method and proceed with normal encoding else
3) encode at normal quant and run the blocking metric again.
4) If the blocking metric is much higher than it was before, apply a debanding/deblocking filter using a dithering method and proceed re-encoding the block.

This method will even improve visual quality if source has already blocking artifacts
Problems with that:

1. What if its meant to be a block to begin with? There are square objects that might get "deblocked" inadvertently.
2. Debanding adds dithering noise, which cannot be kept effectively without a much lower quantizer. It will quite literally be dumped by x264 during encoding.

[Sharktooth]

remove 2) then...
and no, ditering doesnt add noise. dithering doesnt create moving pixels but static pixels, so there are no additional MVs, etc... but since the block will contain more data a lower quantization is needed. just some additional analysis...
there is a possible problem though for referenced blocks...
this procedure may create flickering so the debanding should be temporal...

[woah!]

If you want some fun trying to kill these blocks off, I'd recommend the new Disney production logo sequence that was unveiled with "Pirates: Dead Man's Chest" (still shot (http://upload.wikimedia.org/wikipedia/en/d/dd/Waltdisneypictureslogo.png)). I think it is on "Bridge to Terabinthia" also. I'll check tonight. (Any other sources guys?)

Animated CGI footage with dark, blue, motion, and fine details everywhere! No need to be playing with gamma and tilting your lcd screens and adjusting brightness/contrast. The problems are so evident. It will give AQ/CQM/dead zone settings a run for the money!

i gave your idea a go and use the intro 800frames of POTC2.

heres 2 screenies of it at 1280x720 at 1000 bitrate. low i know but this way it shows the blocks well. i will do a 8000 bitrate next to show the same frames:

Prestige.cfg 1000bitrate
http://www.cif-forums.com/png/115_Pres.png

EQM AVC-HR.CFG 1000bitrate
http://www.cif-forums.com/png/115_AVC_HR.png

Prestige.cfg 8000bitrate
http://www.cif-forums.com/png/720P_INTRO_Prestige_8000BR.png

EQM AVC-HR.CFG 8000bitrate
http://www.cif-forums.com/png/720P_INTRO_EQM AVC-HR_8000BR.png

[Sharktooth]

EQM AVC-HR does a good job at both 1000 and 8000kbps.
however im working to a new matrix that will be even better ;)

[fields_g]

Prestige @ 1k.... I could have made that with legos. :) I know its a starved of its intended bitrate, but if a CQM can make something look so bad, Sharktooth's though of using a CQM to make it better might not be a bad one either!

What command line did you use for these encodes? Do you have the output stats?

After Sharktooth finishes his new CQM, it might be nice to run these and other CQM's in both CRF and VBR modes of various bitrates/levels. Anyone want to partner up with me a do this?

Here's another idea..... wanna move this conversation over to the MPEG-4 AVC forum instead of having it under a thread in the GUI forum under a title for a suggestion that shouldn't happen unless AQ is put into the SVN? (no wonder why people can't find this in search!)

[Terranigma]

woah!, test and compare*.mp4 guy's M4G-V3 CQM ;)

M4G-V3:
INTRA4X4_LUMA =
4,9,18,45,
9,16,35,180,
18,35,225,255,
45,180,255,255

INTRA4X4_CHROMAU =
14,22,32,72,
22,24,41,144,
32,41,96,200,
72,144,200,255

INTRA4X4_CHROMAV =
14,22,32,72,
22,24,41,144,
32,41,96,200,
72,144,200,255

INTER4X4_LUMA =
4,18,18,18,
18,18,18,18,
18,18,18,18,
18,18,18,18

INTER4X4_CHROMAU =
16,22,22,22,
22,22,22,56,
22,22,72,96,
22,56,96,128

INTER4X4_CHROMAV =
16,22,22,22,
22,22,22,56,
22,22,72,96,
22,56,96,128

INTRA8X8_LUMA =
5,8,11,15,18,21,24,35,
8,9,12,17,18,22,25,70,
11,12,18,19,22,30,40,125,
15,17,19,24,35,50,100,155,
18,18,22,35,70,135,160,180,
21,22,30,50,135,175,200,205,
24,25,40,100,160,200,225,230,
35,70,125,155,180,205,230,255

INTER8X8_LUMA =
5,14,16,18,18,18,19,19,
14,15,17,17,17,18,18,18,
16,17,17,17,17,18,18,18,
18,17,17,17,17,18,18,19,
18,17,17,17,17,18,18,19,
18,18,18,18,18,18,18,19,
19,18,18,18,18,18,18,20,
19,19,19,19,19,19,20,20

It's meant for this purpose.

--
I just found this (http://forum.doom9.org/showpost.php?p=799957&postcount=76) and I have to say that that's awesome :eek:

So AVC-HR is meant to retain this kind of detail as well? A miracle matrix? :p

[woah!]

M4G-V3.CFG 1000bitrate
http://www.cif-forums.com/png/720P_INTRO_M4G-V3.CFG_1000BR.png

[Terranigma]

Thanks. So it seems that sharktooth's matrix is better at retaining more detail and being less blocky than m4g-v3's coefficients, but then again, there's a 7000 bitrate difference compared to the other examples. :p

[Sharktooth]

my matrix was thought to retain most of the visible details, dropping frequencies without causing too much "damage" and better quantize lower frequencies to limit the blockiness. also since the matrix forces the encoder to put more bits than flat for every quantizer that will rise the QP for each encoded picture. doing that, the deblocking filter will be triggered more frequently (helping again reducing blocking), while at high bitrates this behaviour will be less evident so details get preserved.
since the matrix it's not 100% tuned there is still room for improving it, but keep in mind that it is "unbalanced"... and that could be bad for some x264 internal stuff (i said x264 since akupenguin once said that unbalanced matrices may screw something, i still dont know if other encoders can bear with that).
however if you encode something and it looks good, then all went good :)

@fields_g: yes, it's time to split the thread...

@Terranigma: i dont do miracles...

[Terranigma]

Sharktooth, do you exactly recall cases where direct auto conflicted with b-rdo? From my personal experiences, I haven't noticed blocking caused by using them together.

[Sharktooth]

no, sorry. my memory is too short to remember. however im sure there was a discussion on the AVC forum

[Terranigma]

No Problem. I have another question. What in-loop values would you recommend to use with your matrix?
-1, -1?

[MarcioAB]

Can I say the conclusion here is that blockness on dark/flat/low motion areas, may be better resolved with a special kind of "Quantization Matrix" than with frame-Adaptive Quantization (AQ) ?

I would like to try on my trouble encode (*).
Can someone indicate where can I get such "special" Quantization matrix ?

Thank you.

(*) By the way, the blockness of my trouble encode, compared with the Bike example posted here, is so worst that I can say the Bike encode is perfect.

[Atak_Snajpera]

Do whatever you want but I still prefer AQ over custom matrix. It's a lot easier for me to adjust two settings instead of playing with those matrixes. Prestige or EQM AVC-HR or maybe M4G-V3... eee waste of time... :P

[Terranigma]

Well you can use adaptive quantization with a custom matrix as well. It would'nt hurt you know. :p
Anyways, i'd like to hear from sharktooth on his recommended in-loop setting with the AVC-HR matrix. :)

[Atak_Snajpera]

Well you can use adaptive quantization with a custom matrix as well.
I see no reason to use these two options together. EQM AVC-HR works well and gives similar quality as AQ with standard matrix but it's restricted only to high profile. I prefer more compatible solution.

[MarcioAB]

I'm using the "EQM AVC-HR" that is in Sharktooth signature, but I understand he is working in something "better" and it's not ready yet.

Anyway I see 3 scenarios:

1) EQM matrix without AQ
2) default matrix with AQ
3) EQM matrix with AQ

My visual classification after quick tests is: (3) > (2) > (1) on the blocky area.

[Sharktooth]

@Terranigma: it all depends on your preferences. I like how it looks with -2,-1 but with different monitors/TV and different eyes it may look completely off.
so try some encodings with short clips and find the values you like most.

[akupenguin]

my matrix was thought to retain most of the visible details, dropping frequencies without causing too much "damage" and better quantize lower frequencies to limit the blockiness. also since the matrix forces the encoder to put more bits than flat for every quantizer that will rise the QP for each encoded picture. doing that, the deblocking filter will be triggered more frequently (helping again reducing blocking), while at high bitrates this behaviour will be less evident so details get preserved.
since the matrix it's not 100% tuned there is still room for improving it, but keep in mind that it is "unbalanced"... and that could be bad for some x264 internal stuff (i said x264 since akupenguin once said that unbalanced matrices may screw something, i still dont know if other encoders can bear with that).
Unbalanced means uses different average number of bits per QP than the flat matrix (or different quality per QP; I'm not sure that bits is exaclty the right measure). If you want to adjust deblocking strength, do that with --deblock not --cqm.
But even more important than matching bitrate of the encode as a whole, is matching the bitrate of each individual matrix to eachother. Prestige is very unbalanced in that the intra matrices take more bits than the inter matrices at the same QP, thus RDO rarely chooses intra even in blocks that don't benefit from inter prediction.

[woah!]

I'm using the "EQM AVC-HR" that is in Sharktooth signature, but I understand he is working in something "better" and it's not ready yet.

Anyway I see 3 scenarios:

1) EQM matrix without AQ
2) default matrix with AQ
3) EQM matrix with AQ

My visual classification after quick tests is: (3) > (2) > (1) on the blocky area.

i would concur with this by using this screenshot :

EQM AVC-HR.CFG 1000bitrate with --aq-sensitivity 10 --aq-strength 0.4

http://www.cif-forums.com/png/720P_INTRO_EQM AVC-HR_1000BR_AQ_0.4_10.bmp

[Sharktooth]

Unbalanced means uses different average number of bits per QP than the flat matrix (or different quality per QP; I'm not sure that bits is exaclty the right measure). If you want to adjust deblocking strength, do that with --deblock not --cqm.
But even more important than matching bitrate of the encode as a whole, is matching the bitrate of each individual matrix to eachother. Prestige is very unbalanced in that the intra matrices take more bits than the inter matrices at the same QP, thus RDO rarely chooses intra even in blocks that don't benefit from inter prediction.
correct me if im wrong, but rising the deblocking settings will compromise picture sharpness too.
the intent here is to have a good sharpness preserving fine details and reduce blocking in flat areas.
also there are some situations where deblocking doesnt help (blue sky issue...) while a CQM or AQ can.