Variance AQ Megathread (AQ v0.48 update--defaults changed)

[ToS_Maverick]

That was easy (http://www.mediafire.com/?5d1fywox22w). Just 600 kilobits, CRF mode, was plenty.

On this topic, it seems CRF mode seems to work fine with AQ if you use a reasonable sensitivity (20).

i can second that, i use --aq-strength 1.0 --aq-sensitivity 15 in CRF mode, works great!

[DeathTheSheep]

15? Didn't he say that was too low? If 20-25 works better, with bias towards the lower end, wouldn't that imply 21-22?

Just beating some weighted averages around. Hoohoo!

[Dark Shikari]

15? Didn't he say that was too low? If 20-25 works better, with bias towards the lower end, wouldn't that imply 21-22?

Just beating some weighted averages around. Hoohoo!I have no idea. You'll have to test.

Ideally, a good "middle value" would result in true Constant Quality, since it would appropriately adjust CRF based on the variance of the video, which defines what bitrate it "really" needs. Technically any decent value of sensitivity would do this--its just that the bitrate would not necessarily be comparable to non-AQ CRF.

[Atak_Snajpera]

http://mirror05.x264.nl/CruNcher/force.php?file=./1.mkv
http://mirror05.x264.nl/CruNcher/force.php?file=./2.mkv
http://mirror05.x264.nl/CruNcher/force.php?file=./3.mkv

1 looks a lot better than 2 or 3.

MPC + FFDShow HQ-RGB32 forced

i can second that, i use --aq-strength 1.0 --aq-sensitivity 15 in CRF mode, works great!
I fully agree with you. 1.0 and 15 seems to be well balanced. However I still prefer auto sensitivity. Better quality (compared to no AQ) plus smaller files in CRF.

[Sagekilla]

Dark Shikari, would it be possible to hack in AQ to be used for RC under CRF mode? (Acronym city!) I'm sure if you did that, you could get even closer to a truer "constant quality"

[Dark Shikari]

Dark Shikari, would it be possible to hack in AQ to be used for RC under CRF mode? (Acronym city!) I'm sure if you did that, you could get even closer to a truer "constant quality"Actually, thinking about it... it should be even better than CRF mode, because it properly takes into account the quantizer needed to reach a constant quality.

Try sensitivity 20 on CRF mode.

[lexor]

hey guys, is anyone else having problems getting the files from x264.nl? I can't get there for a few days now. I thought there was a site hiccup, but seeing how a new video was added there (the one in OP) not everyone is having these issues. Or is it intermittent and I always try it when it's down?

[DeathTheSheep]

Wouldn't a "truer" constant quality be reached using QP and threshold? (To answer my own question, yeah, pretty much. No qcomp hiccups to worry about here, or artificial degradation near keyframes -.-).
:)

[CruNcher]

@Dark Shikari
A strange idea came to my mind :D wouldn't it be possible to implement both AQs @ the same time? yours to enhance the current picture (distribution on the frame) and the old one todo the rest (distribution between the frames)? hmm something like a Mixed-Mode AQ (the most efficient of both worlds combined) :D

[Dark Shikari]

@Dark Shikari
A strange idea came to my mind :D wouldn't it be possible to implement both AQs @ the same time? yours to enhance the current picture (distribution on the frame) and the old one todo the rest (distribution between the frames)? hmm something like a Mixed-Mode AQ :DWouldn't work. The old AQ didn't change framewide QP, it just changed it (in an extremely strong manner) on a few blocks in the frame.

Also, 0.46 is out, see original post for changes.

[fields_g]

Actually, thinking about it... it should be even better than CRF mode, because it properly takes into account the quantizer needed to reach a constant quality.

Try sensitivity 20 on CRF mode.

I WAS trying out the most current version (.45) until SOMEONE wanted to update it! :) Anyway... I'm using my favorite AQ testing material (POTC2 first 34 seconds.. aka the new Disney Logo) @ 1080p. Here's my base command line:

--crf 18 --ref 16 --mixed-refs --no-fast-pskip --bframes 16 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -2,-1 --subme 7 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --me esa --merange 12 --threads auto --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "output" "input" --aq-strength 1.0

Here are some results:
Sensitivity ....Filesize
-------------------------------
Auto.............20.0 MB
10................18.5 MB
11................23.8 MB
15................50.6 MB
25................79.5 MB
NoAQ............20.5 MB


As you can see, on this clip, the sensitivity really blows up the bitrate. Auto does a really good job of following the NoAQ bitrate. When you guys suggest 20, does this produce a filesize that is approximately equal to auto/NoAQ on your clips?

Visually inspecting the results, it is obvious that Auto needs more help. I much prefer the 15 than the Auto or 11 results. This leads me to believe that your suggestion of 20 might not be so bad! Just hoping this doesn't always mean a 3x bitrate at a given CRF!

[CruNcher]

fields_g see it's almost a real VBR mode you get the best possible quality but with it CRF becomes non predictable anymore DABR i think isn't possible this way (or actually has to be new ploted). :) At least the whole CRF shifts the higher you set the Sensitivity CRF 19 with for example --aq-sensitivity 40 would get very very big ;) i would suggest for a Real VBR that reaches Visual Losslesness (Transparency) 50dB here as a good target to test alot of source (the most complex you can find) and see how it comes out CRF 19 and @ wich Sensitivity :)

[fields_g]

I guess there is a reason that it is an AQ test sample for me. It isn't a cakewalk to fix. The bitrate is showing that!

[CruNcher]

25................79.5 MB
how much dB did you reached with it with your settings?

[fields_g]

Playing around earlier I made sure to hit the ssim / pnsr boxes, but this run I didn't. I'll rerun some of these and get those.


EDIT: sensitivity 25 - SSIM .9931239 - PSNR Y55.808 U57.585 V57.585 Avg56.259 Global50.669
Though AQ has to be judged subjectively.

[Dark Shikari]

OK folks, here's a challenge for you!

In order to put the AQ in SVN, we're going to need to decide on a good general sensitivity to use that would keep bitrate relatively constant on a large sample of different types of video. That is, a flat video might get higher bitrate, and a complex one lower, but in general, on a large sample of a bunch of random stuff, it shouldn't change the bitrate at all in CRF mode.

So, grab yourself a ton of selecteveryrange() and find me a sensitivity that doesn't change bitrate at all on a combination of many sources. Once we get that sensitivity, I will likely remove the sensitivity option completely and simply have two modes--automatic and static.

[fields_g]

OK folks, here's a challenge for you!

In order to put the AQ in SVN, we're going to need to decide on a good general sensitivity to use that would keep bitrate relatively constant on a large sample of different types of video. That is, a flat video might get higher bitrate, and a complex one lower, but in general, on a large sample of a bunch of random stuff, it shouldn't change the bitrate at all in CRF mode.

Is the idea to also get rid of --aq-strength also? Should we be testing at 1.0 or a variety of strengths and comparing to NoAQ?

[Dark Shikari]

Is the idea to also get rid of --aq-strength also? Should we be testing at 1.0 or a variety of strengths and comparing to NoAQ?Nah, just compare strength 1.0 to strength 0, since 1.0 is meant to be a good default.

AQ strength should always be adjustable.

[CruNcher]

does someone has the EBU testsequence they test broadcast codecs with i think that would be perfect a mix of the schumacher and alot of other testclips that is :)

http://www.ebu.ch/en/technical/hdtv/test_sequences.php

[desta]

I'm assuming DS means finding a sensitivity that gives the same final bitrate as using no AQ. The sensitivity being the same or pretty close when applied to various samples.

Edit: too late.

[burfadel]

Who else thinks it would be better, in general, to have aq-strength 1.0 set as default (that is, without the need to actually specify it at all), but still have it adjustable by the addition of the --aq-strength x.x command?

[Dark Shikari]

Who else thinks it would be better, in general, to have aq-strength 1.0 set as default (that is, without the need to actually specify it at all), but still have it adjustable by the addition of the --aq-strength x.x command?I'm going to leave in AQ strength. Having it on by default might definitely be useful, if akupenguin would allow it.

[CruNcher]

Btw Dark i fixed all this problems in those scenes by combining your aq with the prestige matrix :) now i have both of best worlds your enhanced detail preservation + a fix for those ROI problems im uber happy (no banding situations anymore) :)

http://mirror05.x264.nl/CruNcher/force.php?file=./roi-fixed-newaq.mkv <- combined result still 0.45 :)

This is the most advanced lossy encode i ever did :)

[Morte66]

OK folks, here's a challenge for you!

In order to put the AQ in SVN, we're going to need to decide on a good general sensitivity to use that would keep bitrate relatively constant on a large sample of different types of video. That is, a flat video might get higher bitrate, and a complex one lower, but in general, on a large sample of a bunch of random stuff, it shouldn't change the bitrate at all in CRF mode.

Let me see if I understand this...

Current CRF implies a certain level of quality (crispness, fine detail retention etc), but the judgement of quality places more weight on complex material relative to flat areas than humans do. Current CRF (without AQ) is not a constant quality mode as judged by humans.

With current CRF/AQ, CRF achieves the same level of quality on complex stuff and AQ throws extra bitrate at flat areas. It maintains the quality of plain CRF on complex material, and improves flat material with extra bitrate. Overall bitrate rises. It gets closer to constant quality as perceived by humans. [I like this -- for me the point of CRF is to give constant quality by spending whatever bitrate is necessary.]

VAQ, however, nabs bitrate from complex areas to improve flat areas (both within and optionally between frames). So if CRFVAQ (hey, a new acronym) maintains the bitrate of plain CRF, will it look worse on complex stuff and better on smooth? Will a particularly shadowy episode of the X-Files look less crisp and detailed in its complex areas than one which is visually busy? Will "CRF 18" no longer imply a certain level of crispness and fine detail on the complex stuff? Or have I completely misunderstood it?

[DarkZell666]

From what I gathererd, an important change is rather the method used to distinguish/define what's complex and what isn't.

You'd think the new AQ munches fine details since it supposedly takes bitrate out of complex scenes, but CruNcher's screenshots actually show some extra detail on people's faces and in flying particles :)


Just my 0.02€ ^^ :helpful:

[akupenguin]

@Morte66
Current CRF is constant quality as measured by one particular metric (not psnr or ssim or any of the normal metrics, but an ad-hoc one implicit in the CRF algorithm). It's similar bitrate on average as the same value of CQP, because I multiplied the CRF scale by a magic number to make that true, not by anything inherent in the algorithm.
CRF+HaaliAQ is constant quality as measured by another metric. It's always at least a little higher bitrate per CRF value than plain CRF because HaaliAQ has a negative average QP bias, but that's just a UI tuning issue and could be fixed if desired.
CRF+VAQ(static) is constant quality as measured by another metric. If you pick some random value of aq-sensitivity, it won't be equal on average, but will have some bias. We're trying to find a sensitivity value such that that bias averages to 0, thus it will hopefully be about the same bitrate on average as a given value of plain CRF if we do the tuning right (unless we choose to keep psy quality the same instead of bitrate).
CRF+VAQ(auto) does the frame-wise bit allocation using the same metric as plain CRF, but reallocates bits within the frame using the VAQ metric.

In short, there's no substantive difference between "improves smooth stuff at the cost of complex stuff" and "improves smooth stuff while keeping complex stuff the same". The only criterion AQ can be judged by is the relative distribution of quality. Any bias in the total quality is just a user interface issue separate from the algorithm.

[Morte66]

In short, there's no substantive difference between "improves smooth stuff at the cost of complex stuff" and "improves smooth stuff while keeping complex stuff the same". The only criterion AQ can be judged by is the relative distribution of quality. Any bias in the total quality is just a user interface issue separate from the algorithm.

*digests*

OK, I see what you mean. That makes good sense to me. Thank you.

So if I found that...

- plain crf 18 creates a 350MB file with satisfactory complex stuff but unsatisfactory smooth stuff

- crf 18 with Haali --aq-strength 0.3 --aq-sensitivity 5 creates a 600MB file which is satisfactory on complex and flat

- crf 18 with variance --aq-strength 1.0 --aq-sensitivity 15 creates a 350MB file which is better overall than either of the above, but occasionally loses a little on the complex stuff

... then I ought to try using variance AQ and changing crf to 17, hoping to get quality that is equal or better in every respect to the 600MB Haali AQ encode in perhaps 400MB?

[LoRd_MuldeR]

@Morte66
Current CRF is constant quality as measured by one particular metric (not psnr or ssim or any of the normal metrics, but an ad-hoc one implicit in the CRF algorithm). It's similar bitrate on average as the same value of CQP, because I multiplied the CRF scale by a magic number to make that true, not by anything inherent in the algorithm.
CRF+HaaliAQ is constant quality as measured by another metric. It's always at least a little higher bitrate per CRF value than plain CRF because HaaliAQ has a negative average QP bias, but that's just a UI tuning issue and could be fixed if desired.
CRF+VAQ(static) is constant quality as measured by another metric. If you pick some random value of aq-sensitivity, it won't be equal on average, but will have some bias. We're trying to find a sensitivity value such that that bias averages to 0, thus it will hopefully be about the same bitrate on average as a given value of plain CRF if we do the tuning right (unless we choose to keep psy quality the same instead of bitrate).
CRF+VAQ(auto) does the frame-wise bit allocation using the same metric as plain CRF, but reallocates bits within the frame using the VAQ metric.

In short, there's no substantive difference between "improves smooth stuff at the cost of complex stuff" and "improves smooth stuff while keeping complex stuff the same". The only criterion AQ can be judged by is the relative distribution of quality. Any bias in the total quality is just a user interface issue separate from the algorithm.

Thanks for the explanation. Very interesting post :)

[ToS_Maverick]

OK folks, here's a challenge for you!

In order to put the AQ in SVN, we're going to need to decide on a good general sensitivity to use that would keep bitrate relatively constant on a large sample of different types of video. That is, a flat video might get higher bitrate, and a complex one lower, but in general, on a large sample of a bunch of random stuff, it shouldn't change the bitrate at all in CRF mode.

So, grab yourself a ton of selecteveryrange() and find me a sensitivity that doesn't change bitrate at all on a combination of many sources. Once we get that sensitivity, I will likely remove the sensitivity option completely and simply have two modes--automatic and static.

hey i got some results for you!

aq10 means --aq-strength 1.0
sens15 means --aq-sensitivity 15
and so on

BlackPearlSample (3622 frames):

Black.Pearl.Sample test crf 18 aq00.mkv 35,3 MB
Black.Pearl.Sample test crf 18 aq10 sens13.mkv 35 MB
Black.Pearl.Sample test crf 20 aq10 sens15.mkv 32,6 MB
Black.Pearl.Sample test crf 22 aq10 sens18.mkv 33,3 MB
Black.Pearl.Sample test crf 24 aq10 sens21.mkv 32,1 MB
Black.Pearl.Sample test crf 26 aq10 sens25.mkv 32,3 MB


SAW 1 DVD comp check (1488 frames):

SAW test crf 18 aq00.mkv 15,5 MB
SAW test crf 18 aq10 sens12.mkv 15,7 MB
SAW test crf 18 aq10 sens13.mkv 19,4 MB


Klick from HDTV comp check (1548 frames):

klick comp test crf 18 aq00.mkv 49,7 MB
klick comp test crf 18 aq10 sens12.mkv 42,5 MB
klick comp test crf 18 aq10 sens13.mkv 50,9 MB


what i found out:
- 3 steps in sensitivity roughly equals 2 steps in CRF
- sensitivity 13 seems to be a good pick (for now) if you want the same CRF filesize with and without AQ

[Chabb]

Would it be right to use AQ with lowered deadzones and custom quantization matrixes? Please express any pro et contra.

[Morte66]

Entourage Season 2 Episode 11 with AviSynth levels/deblock/denoise/deband -> huffYUV, then x264 crf 18 encode. FWIW I've put what I thought of the quality in brackets.

Variance AQ build 46 but no AQ set: 372MB (unsatisfactory)
Variance AQ strength 1.0 sensitivity 15: 326MB (about the same quality but smaller)
Variance AQ strength 1.0 sensitivity 17: 378MB (barely satisfactory, only saw problems if I looked for them)
Variance AQ strength 1.0 sensitivity 20: 516MB (comfortable, maybe diminished returns)

Well, based on that completely inadequate pool of data I'd make --aq-sensitivity a parameter that defaults to 17.

@TOS_Maverick: you got a much lower number. Did you pre-process in any way? Maybe because I deblocked/denoised/debanded my video has more "smooth/flat" in it.

[DeathTheSheep]

Would it be right to use AQ with lowered deadzones and custom quantization matrixes? Please express any pro et contra.

Pro:
Btw Dark i fixed all this problems in those scenes by combining your aq with the prestige matrix :) now i have both of best worlds your enhanced detail preservation + a fix for those ROI problems im uber happy (no banding situations anymore) :)

http://mirror05.x264.nl/CruNcher/force.php?file=./roi-fixed-newaq.mkv <- combined result still 0.44 :)

This is the most advanced lossy encode i ever did :)

Contra: Not much has been said about deadzones, so more testing has to be done.

[CruNcher]

It seems with useing a custom matrix you can have an influence on how Darks NewAQ behaves on the Frame for example what you will see here is that both combined are like a AI AQ for this testcut (it seems almost to decide magicaly were the scene could band and then allocates more bits into this area)
This is perfect Visually as it enhances allways the right area :)
So if there is no banding possibility it will enhance (Facial Details) if their could banding happen (it does enhance the background with the gradients).
I know it's not AI but the balance that i shifted this way by useing a custom matrix, tough still 1 scene gives me major headaches Visually ;)

Noaq
http://s5.directupload.net/images/080124/9u87knfx.png
http://s6.directupload.net/images/080124/g7owp2vh.png (this scene is the Visual killer, especialy when the viewing system is wrong calibrated)
http://s2.directupload.net/images/080124/rqsiveqs.png
http://s5.directupload.net/images/080124/qj6gkjzb.png
http://s1.directupload.net/images/080124/fi6pqiwd.png
http://s3.directupload.net/images/080124/9xfz7l2t.png
http://s3.directupload.net/images/080124/bf8kl9uw.png

Newaq
http://s2.directupload.net/images/080124/idkvrpus.png
http://s5.directupload.net/images/080124/ge4gmtph.png
http://s6.directupload.net/images/080124/8apvaqwh.png
http://s2.directupload.net/images/080124/j32kt8zb.png
http://s3.directupload.net/images/080124/pe7f62ej.png
http://s5.directupload.net/images/080124/sf3up4fl.png
http://s4.directupload.net/images/080124/4qr7pot6.png

But i think i still need to balance it out a little as you can see ringing (to sharp) appearing, btw Prestige Matrix does the shifting in this case very precise dunno what some have against this matrix it seems visually optimized entirely for grain preservation and it does a good job i can also see no artifacts @ all, coused by it (except the sligth ringing effect coused by overoptimizing the source visually with this) :)

[Morte66]

Maybe because I deblocked/denoised/debanded my video has more "smooth/flat" in it.

So I ran it again with all the crud left in, just doing levels. This time:

crf 18 no AQ: 623MB
crf 18 VAQ strength 1.0 sensitivity 17: 932MB (sensitivity 17 matched sizes when cleaned up)
crf 18 VAQ strength 1.0 sensitivity 13: 559MB (13 seemed closest for TOS_Maverick's tests)
crf 18 VAQ strength 1.0 sensitivity 14: 648MB (and 14 is closest for my uncleaned DVD)

So if I feed in a middle of the road DVD with no cleanup, I get results fairly similar to TOS_Maverick (sensitivity ~13 matches no AQ). For a cleaned up DVD, which doesn't have crud all over the smooth/dark content making it un-smooth, it needed to be 3 or 4 higher.

[bob0r]

AQ patch 0.47: http://akuvian.org/src/x264/x264_aq_var.47.diff

x264.721.dark.aq.0.47.exe (http://files.x264.nl/AQ/x264.721.dark.aq.0.47.exe) (pthreads/mp4 = yes, made with make fprofiled)

[Terranigma]

Thanks for that bob0r. :)

[Dark Shikari]

AQ patch 0.47: http://akuvian.org/src/x264/x264_aq_var.47.diff

x264.721.dark.aq.0.47.exe (http://files.x264.nl/AQ/x264.721.dark.aq.0.47.exe) (pthreads/mp4 = yes, made with make fprofiled)Can you guys do your testing again with this patch? It vastly cleaned up the code, and more importantly, it fixed a rounding error with low QPs which should somewhat improve visual quality in flat areas. However, this may change the results of your sensitivity tests.

[DeathTheSheep]

The fact that this patch has been worked on by akupenguin (and is now hosted on his site) of no small significance or import, and perhaps signals the coming of something momentous.

A rounding error was fixed? What's the likelihood of any quality difference occurring at high QP?

[Dark Shikari]

The fact that this patch has been worked on by akupenguin (and is now hosted on his site) of no small significance or import, and perhaps signals the coming of something momentous.

A rounding error was fixed? What's the likelihood of any quality difference occurring at high QP?I'm referring to the lower QPs *in the video*, i.e. the flat areas that get lowered a lot. Areas with low variance.

Not low QPs as a general statement.

Previously, variance was calculated as (SSD - (SAD / 16) ^2). Now its calculated as (SSD - SAD^2 / 256).

[DeathTheSheep]

Ouch. In that case, there's almost guaranteed to be a [somewhat] positive difference on the very places that count most.

[Morte66]

Can you guys do your testing again with this patch?

Arrgh! Just as I've nearly finished the 1080p test. ;)

I did the Taurus media samples, which are uncompressed footage from a digital camera. They're very busy, not much smooth/flat stuff, so they're not really a good surrogate for film/TV. But I've never been able to resist testing them since I spent three whole days downloading them.

crf 18 no AQ: 228MB
crf 18 VAQ strength 1.0 sensitivity 17: 381MB
crf 18 VAQ strength 1.0 sensitivity 14: 203MB

That's with 0.46.

[DeathTheSheep]

.47 makes the files balloon in size at the same threshold I was using before (22 in this particular test case).

Seems quite a bit slower, but maybe this can be explained by the fact that my "old" settings apparently correspond to different things now.

[edit]
[I said edit, where's the edit notifier at the bottom? ...that's better.]
SSIM just...went...through...the...roof...... (I'm going to have to re-shingle now, damn it).

[Dark Shikari]

.47 makes the files balloon in size at the same threshold I was using before (22 in this particular test case).

Seems quite a bit slower, but maybe this can be explained by the fact that my "old" settings apparently correspond to different things now.Yeah, due to rounding, 0.46 wasn't giving flat blocks low enough quantizers.

[ditche]

I don't understand...

I've encoded a movie (duration : 1h52) with theses settings :
--qp 22 --ref 10 --mixed-refs --no-fast-pskip --bframes 16 --b-pyramid --bime --weightb --direct auto --filter -2,-1 --trellis 2 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads 3 --thread-input --sar 1:1 --progress --no-dct-decimate --no-psnr --no-ssim --output "D:\VIDEO\rip\video.mp4" "D:\VIDEO\rip\video.avs" --aq-strength 1.0
CRF : 22, resolution : 688x304, x264 721 0.45

Results : 339 Mo @ CRF22 for 1h52.
Fun, tiny size, but...

Nop, because the result is very bad...

http://img134.imageshack.us/img134/7029/snapshot20080124230054ib5.th.jpg (http://img134.imageshack.us/my.php?image=snapshot20080124230054ib5.jpg)

http://img134.imageshack.us/img134/94/snapshot20080124230249cm7.th.jpg (http://img134.imageshack.us/my.php?image=snapshot20080124230249cm7.jpg)

My other encodings with same settings give me larger files but a good quality...
:confused:


Have you an idea ? Thanks. :)

:helpful:

[Dark Shikari]

Those are somewhat odd settings you're using, plus, you're using QP mode, not CRF mode. Trellis 2 doesn't help detail retention, either.

I suspect you're just not giving it enough bits.

[Atak_Snajpera]

Since when --qp 22 means --crf 22 ?

[ditche]

Since when --qp 22 means --crf 22 ?
Arf !! :)
I make a little confusion between qp & crf... :p

[LoRd_MuldeR]

Since when --qp 22 means --crf 22 ?

ditche, according to your command-line you were using --qp 22, but you said "CRF : 22" :p

[ditche]

Yeah, I'm confused...

It's almost midnight here, tomorrow i'll try with theses settings, is it OK for you (± Shartooth settings :p) ?

--crf 22.0 --ref 3 --mixed-refs --bframes 16 --b-pyramid --bime --weightb --filter -2,-1 --subme 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --output "output" "input" --aq-strength 1.0 --aq-sensitivity 15

:)


Edit :
Ah, it's looks so much better on my last sample test. :)

[Dark Shikari]

Those are really bizarre settings--UMH/8x8dct/many refs, but subme 1?!