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

[DeathTheSheep]

Da...kaz...? :eek:

[Dark Shikari]

Da...kaz...? :eek:x264 is not only used by hobbyists, you know... :)

[bob0r]

I find these results stunning:

No AQ:
x264.exe --pass 2 --bitrate 3096 --threads auto --deblock 0:0 --bframes 3 --b-pyramid --bime --weightb --b-rdo --me umh --ref 5 --mixed-refs --subme 7 --trellis 1 --analyse all --8x8dct --no-fast-pskip --progress --fps=25 --output x264aq.mkv 720p50_parkrun_ter.yuv 1280x720
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSE3 SSSE3 Cache64
x264 [info]: slice I:3 Avg QP:25.33 size:131303 PSNR Mean Y:41.13 U:42.91 V:45.56 Avg:41.78 Global:38.10
x264 [info]: slice P:233 Avg QP:34.52 size: 29549 PSNR Mean Y:29.02 U:36.95 V:39.19 Avg:30.50 Global:30.22
x264 [info]: slice B:268 Avg QP:35.70 size: 2964 PSNR Mean Y:29.10 U:37.13 V:39.35 Avg:30.56 Global:29.96
x264 [info]: mb I I16..4: 27.9% 66.2% 6.0%
x264 [info]: mb P I16..4: 0.3% 0.8% 0.3% P16..4: 46.4% 12.1% 9.8% 1.0% 0.7% skip:28.7%
x264 [info]: mb B I16..4: 0.0% 0.0% 0.0% B16..8: 17.4% 0.1% 0.4% direct: 3.1% skip:79.0%
x264 [info]: 8x8 transform intra:60.9% inter:56.9%
x264 [info]: ref P 80.2% 9.6% 6.0% 2.2% 2.0%
x264 [info]: ref B 87.2% 5.4% 3.9% 2.1% 1.3%
x264 [info]: SSIM Mean Y:0.8698542
x264 [info]: PSNR Mean Y:29.138 U:37.082 V:39.312 Avg:30.597 Global:30.099 kb/s:3203.68
encoded 504 frames, 9.37 fps, 3202.74 kb/s

AQ:
x264.exe --pass 2 --bitrate 3096 --threads auto --aq-strength 1.0 --deblock 0:0 --bframes 3 --b-pyramid --bime --weightb --b-rdo --me umh --ref 5 --mixed-refs --subme 7 --trellis 1 --analyse all --8x8dct --no-fast-pskip --progress --fps=25 --output x264aq.mkv 720p50_parkrun_ter.yuv 1280x720
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSE3 SSSE3 Cache64
x264 [info]: slice I:3 Avg QP:24.67 size:138018 PSNR Mean Y:40.74 U:42.93 V:45.56 Avg:41.47 Global:38.03
x264 [info]: slice P:233 Avg QP:33.93 size: 30242 PSNR Mean Y:28.66 U:37.06 V:39.26 Avg:30.16 Global:29.88
x264 [info]: slice B:268 Avg QP:35.23 size: 2405 PSNR Mean Y:28.75 U:37.24 V:39.42 Avg:30.23 Global:29.63
x264 [info]: mb I I16..4: 26.9% 66.5% 6.5%
x264 [info]: mb P I16..4: 0.2% 0.9% 0.3% P16..4: 50.3% 15.7% 11.6% 0.7% 0.3% skip:20.1%
x264 [info]: mb B I16..4: 0.0% 0.0% 0.0% B16..8: 20.5% 0.1% 0.4% direct: 1.4% skip:77.6%
x264 [info]: 8x8 transform intra:66.3% inter:56.9%
x264 [info]: ref P 81.7% 8.8% 5.5% 2.1% 1.9%
x264 [info]: ref B 84.3% 7.3% 4.6% 2.3% 1.5%
x264 [info]: SSIM Mean Y:0.9032475
x264 [info]: PSNR Mean Y:28.781 U:37.189 V:39.386 Avg:30.266 Global:29.768 kb/s:3216.25
encoded 504 frames, 9.47 fps, 3215.30 kb/s

x264noaq3mbit.0.43.mkv (http://files.x264.nl/AQ/x264noaq3mbit.0.43.mkv) = 7.70 MB (8,078,599 bytes)
x264aq3mbit.0.43.mkv (http://files.x264.nl/AQ/x264aq3mbit.0.43.mkv) = 7.73 MB (8,110,271 bytes)

Screenshots may show local difference, in some parts the NOAQ is slightly better (the bits have to come from somewhere), but just look at these samples in motion!

Edit:
Here is the x264.exe with the patch: x264.720.dark.aq.rdrc.0.431.exe (http://files.x264.nl/AQ/x264.720.dark.aq.rdrc.0.431.exe) (pthreads/mp4 = yes, not made with make fprofiled)

[CruNcher]

yep that's even the same quality as i saw last time from Atemes Encoder :) it's a big step for X264.
i wonder if Mainconcepts Encoder can handle that now last time i saw it it couldn't :)


Reduced I-Frame Closed Gop Pulseing
http://mirror05.x264.nl/CruNcher/parkrun-newaq-reduced-iframe-pulseing.mkv

Still Realtime Encoded ABR 1Pass :)

[Don_Genaro]

I have done several encodings with Dark´s patch and comparint them to some without it. I have noticed a sustancial reduction in the size of the final stream.

Using CRF 21,22,23,24 the resulting files (Using the Patch) end with just 84% of the size of the files that don´t use the patched encoder and with no noticebly loss of quality (maybe even a gain in quality). Very good! :cool:

[Sagekilla]

I'll be testing the new AQ on a notoriously dark movie (Chronicles of Riddick anyone? I'll follow up on Pitch Black, which is even worse) Will post results as soon as my encoding finishes, which should be sometime around 5 PM tomorrow, for at least the AQ'd version. The non-AQ may not finish by then.

Edit: A cursory glance of the video using aq strength of 1 shows the new algo dealing with dark details very well. I'm viewing it before PC scale correction to exaggerate the blocking and I see a lot of detail in areas where normally the detail would be decimated.

[Razorholt]

Here is the x264.exe with the patch: x264.720.dark.aq.rdrc.0.431.exe (http://x264.nl/x264.720.dark.aq.rdrc.0.431.exe) (pthreads/mp4 = yes, not made with make fprofiled)

What's the difference between that build and the one on the OP?

[Dark Shikari]

What's the difference between that build and the one on the OP?Faster, statically built... minor differences though.

[Razorholt]

Thanks Darky for the previous answer. Also:

1. Since I'm using your GrainOptimizer, do you recommend using P4x4 with the new AQ?

2. How about intra? Have you fixed the bug or should I stick to Trellis?


Thanks,
- Dan

[Dark Shikari]

Thanks Darky for the previous answer. Also:

1. Since I'm using your GrainOptimizer, do you recommend using P4x4 with the new AQ?GrainOptimizer shouldn't get a specific benefit from p4x4 now, since the later versions have the blocks try to flip all at once when possible.
2. How about intra? Have you fixed the bug or should I stick to Trellis?


Thanks,
- DanThe bug was fixed a while ago--I removed the lambda-based AQ. Deadzone/trellis are both fine.

[Sagekilla]

Just thought about something.. I'd like to request a new feature for your AQ: sensitivity offset. It would only apply to automatic mode for obvious reasons. Would be nice to force AQ to be slightly more (or less) sensitive sometimes while using the same strength.

Edit: CoR is averaging 1400 kbps and looks great with your new AQ.

[Reuf Toc]

I've made a test on an animation clip mixing totaly flat parts and finely textured parts and I must say that the result is bluffing. AQ reduce considerably blocking and banding while retain a lot more details. Here are some pictures to illustrate my point :

Frame 120 :

AQ (http://reuf.toc.free.fr/AQ/120_AQ.png)
no AQ (http://reuf.toc.free.fr/AQ/120_no_AQ.png)

Frame 350 :

AQ (http://reuf.toc.free.fr/AQ/350_AQ.png)
no AQ (http://reuf.toc.free.fr/AQ/350_no_AQ.png)


x264 command line :

"C:\Program Files\megui\tools\x264\x264.exe" --pass 2 --bitrate 3000 --stats "E:\factory.stats" --level 4.1 --ref 3 --mixed-refs --no-fast-pskip --bframes 16 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -1,-1 --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --sar 1:1 --progress --no-dct-decimate --output "E:\factory AQ 3M.mkv" "E:\factory.avs" --aq-strength 1.0

Log from the clip with AQ :

x264 [info]: slice I:7 Avg QP:24.43 size: 37380 PSNR Mean Y:42.64 U:44.68 V:45.30 Avg:43.23 Global:42.14
x264 [info]: slice P:986 Avg QP:26.31 size: 15043 PSNR Mean Y:40.72 U:43.05 V:43.30 Avg:41.34 Global:40.33
x264 [info]: slice B:347 Avg QP:27.21 size: 5232 PSNR Mean Y:40.16 U:42.82 V:42.35 Avg:40.76 Global:39.68

x264 [info]: mb I I16..4: 33.3% 50.7% 16.0%
x264 [info]: mb P I16..4: 14.2% 13.8% 2.0% P16..4: 40.4% 11.1% 3.4% 0.0% 0.0% skip:15.1%
x264 [info]: mb B I16..4: 0.6% 0.9% 0.2% B16..8: 36.9% 1.1% 2.4% direct: 0.6% skip:57.2%

x264 [info]: 8x8 transform intra:46.3% inter:65.3%
x264 [info]: direct mvs spatial:82.7% temporal:17.3%
x264 [info]: ref P 88.1% 8.0% 3.9%
x264 [info]: ref B 86.4% 8.8% 4.8%

x264 [info]: SSIM Mean Y:0.9667820
x264 [info]: PSNR Mean Y:40.589 U:43.001 V:43.068 Avg:41.199 Global:40.158 kb/s:3025.50

Log from the clip without AQ :

x264 [info]: slice I:7 Avg QP:25.57 size: 41877 PSNR Mean Y:43.93 U:45.58 V:46.10 Avg:44.44 Global:43.37
x264 [info]: slice P:986 Avg QP:27.68 size: 14984 PSNR Mean Y:41.56 U:43.74 V:43.95 Avg:42.14 Global:41.04
x264 [info]: slice B:347 Avg QP:28.50 size: 5379 PSNR Mean Y:40.77 U:43.42 V:42.95 Avg:41.37 Global:40.26

x264 [info]: mb I I16..4: 53.7% 29.4% 16.9%
x264 [info]: mb P I16..4: 25.3% 6.3% 2.0% P16..4: 31.7% 11.1% 3.7% 0.0% 0.0% skip:19.8%
x264 [info]: mb B I16..4: 0.8% 0.6% 0.2% B16..8: 32.1% 1.3% 2.8% direct: 0.6% skip:61.5%

x264 [info]: 8x8 transform intra:19.2% inter:63.5%
x264 [info]: direct mvs spatial:82.7% temporal:17.3%
x264 [info]: ref P 88.8% 7.5% 3.7%
x264 [info]: ref B 86.0% 9.0% 5.0%

x264 [info]: SSIM Mean Y:0.9659700
x264 [info]: PSNR Mean Y:41.370 U:43.665 V:43.700 Avg:41.953 Global:40.830 kb/s:3029.81


Here are the link for the two clip (16,1 MB) :

With AQ (http://reuf.toc.free.fr/AQ/factory_AQ.mkv)
Without AQ (http://reuf.toc.free.fr/AQ/factory_no_AQ.mkv)

Mirror on sendspace and mediafire if my FTP is too slow (33,3MB) :

Sendspace (http://www.sendspace.com/file/29ewp5)
Mediafire (http://www.mediafire.com/?499bz1j3w23)

[Dark Shikari]

And finally, the last bug... interlacing is fixed!

After a whole lot of CABAC debugging, narrowing down the bug, and finally a very good bug-spot by akupenguin, we found and fixed a bug in x264's handling of the CABAC encoding of mb_qp_delta with interlaced video.

Build and patch updated.

[Sharktooth]

@Reuf Toc: results are quite impressive. however, even if the second pic has less blocking, some details are missing (right side of the pic. look at details behind the colored smoke) but i guess the pic looks globally better.

@Dark Shikari: it seems you made CQMs a thing of the past. good job :)

[CruNcher]

Im looking forward to see Sagekillas Dark Encoding results because their it showed flaws to me with my test encode, tough it's still better then without any AQ at all, but not as good as the Old AQ in such specific situations. To enhance Dark Scenes a little more with this AQ it seems you have to lower --aq-strength from the 1.0 setting down this gives then a boost in Dark Sequences but it seemes to be not really visible @ all so 1.0 seems also for such scenes the most efficient if you don't wan't todo segmented Encoding with different AQ strengths ;)

@Dark
Did you tried your New AQ on your Vendeta Sample ?

[foxyshadis]

Hey, you didn't use 721. ;_; Like Chainmax, I'd still like to test this with prepass SATD ESA, but concentrate on what you think will make the best improvement.

I wonder how your elephant's dream running scene would look at this point.

[bob0r]

source:
ftp://ftp.ldv.e-technik.tu-muenchen.de/pub/test_sequences/720p/720p50_parkrun_ter.yuv

commandline:
aq:
start /belownormal /b /w x264.exe --pass 1 --bitrate 5096/3096 --threads auto --aq-strength 1.0 --thread-input --deblock 0:0 --bframes 3 --me dia --ref 1 --subme 1 --no-dct-decimate --partitions none --progress --fps=25 --output NUL 720p50_parkrun_ter.yuv 1280x720
start /belownormal /b /w x264.exe --pass 2 --bitrate 5096/3096 --threads auto --aq-strength 1.0 --thread-input --deblock 0:0 --bframes 3 --b-pyramid --bime --weightb --b-rdo --me umh --ref 5 --mixed-refs --subme 7 --trellis 1 --analyse all --8x8dct --no-fast-pskip --progress --fps=25 --output x264aq.mkv 720p50_parkrun_ter.yuv 1280x720

no aq:
start /belownormal /b /w x264.exe --pass 1 --bitrate 5096/3096 --threads auto --thread-input --deblock 0:0 --bframes 3 --me dia --ref 1 --subme 1 --no-dct-decimate --partitions none --progress --fps=25 --output NUL 720p50_parkrun_ter.yuv 1280x720
start /belownormal /b /w x264.exe --pass 2 --bitrate 5096/3096 --threads auto --thread-input --deblock 0:0 --bframes 3 --b-pyramid --bime --weightb --b-rdo --me umh --ref 5 --mixed-refs --subme 7 --trellis 1 --analyse all --8x8dct --no-fast-pskip --progress --fps=25 --output x264aq.mkv 720p50_parkrun_ter.yuv 1280x720

Change bitrate.

3mbit:
x264noaq3mbit.0.44.mkv (http://files.x264.nl/AQ/x264noaq3mbit.0.44.mkv)
x264aq3mbit.0.44.mkv (http://files.x264.nl/AQ/x264aq3mbit.0.44.mkv)

5mbit:
x264noaq5mbit.0.44.mkv (http://files.x264.nl/AQ/x264noaq5mbit.0.44.mkv)
x264aq5mbit.0.44.mkv (http://files.x264.nl/AQ/x264aq5mbit.0.44.mkv)

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

[CruNcher]

Hey, you didn't use 721. ;_; Like Chainmax, I'd still like to test this with prepass SATD ESA, but concentrate on what you think will make the best improvement.

I wonder how your elephant's dream running scene would look at this point.

the scene with the fine green moving plasma gradient in the background is much more problematic (visual blockfest) (low bitrate) for alot encoders then the running scene itself :D

[Dark Shikari]

Im looking forward to see Sagekillas Dark Encoding results because their it showed flaws to me with my test encode, tough it's still better then without any AQ at all, but not as good as the Old AQ in such specific situations. To enhance Dark Scenes a little more with this AQ it seems you have to lower --aq-strength from the 1.0 setting down this gives then a boost in Dark Sequences but it seemes to be not really visible @ all so 1.0 seems also for such scenes the most efficient if you don't wan't todo segmented Encoding with different AQ strengths ;)
The issue here is likely one of the automatic sensitivity; because the adaptive quantization is unwilling to move bits between frames, it chooses too low a sensitivity on such frames.

Wait, you're saying LOWERING the AQ strength gives a boost in dark sequences? That seems nonsensical.

[tetsuo55]

Is there any reason why i should not be using this (besides the slower encoding time)

[Dark Shikari]

Is there any reason why i should not be using this (besides the slower encoding time)The encoding time difference is extremely minimal at this point.

Reasons you shouldn't be using it:

1) Your source doesn't seem to benefit from it (unlikely, but some cartoons at low bitrates seemed to suffer in my early tests).

2) uh, I can't think of anything else... :p

Some people seem to be pressing to make this an x264 default, even though its not even in SVN yet :)

[DeathTheSheep]

Like Chainmax, I'd still like to test this with prepass SATD ESA...


Woah, add me to the group. I'm stuck with 681.

[tetsuo55]

The encoding time difference is extremely minimal at this point.

Reasons you shouldn't be using it:

1) Your source doesn't seem to benefit from it (unlikely, but some cartoons at low bitrates seemed to suffer in my early tests).

2) uh, I can't think of anything else... :p

Some people seem to be pressing to make this an x264 default, even though its not even in SVN yet :)

~Default~ ~default~ ~default~

[CruNcher]

Dark why does your build creates every run (small) different results? isn't your AQ deterministic?
And yes exactly that's whats happening with the scene you also have lowering the AQ-strength improves it (bitrate increase) higher SSIM, highering it lowers SSIM (bitrate decrease).

[Dark Shikari]

Dark why does your build creates every run (small) different results? isn't your AQ deterministic?It should be 100% deterministic. Is it deterministic without AQ enabled?

[ToS_Maverick]

nope it isn't, with our without AQ

[Dark Shikari]

nope it isn't, with our without AQSounds like its not my problem then :p

[CruNcher]

nope it isn't, with our without AQ

Strange for me it's only non deterministic with AQ enabled without it i get every run the same results with it every run small differences.
--aq-strength 0 (allways the same results) without --aq-strength on the commandline same results every run as with --aq-strength 0 and with parkrun starting with --aq-strength 0.4 allways different results each run.

1st run = SSIM Mean Y:0.8447759
2nd run = SSIM Mean Y:0.8439500
3rd run = SSIM Mean Y:0.8447161
4rd run = SSIM Mean Y:0.8446099

Settings = x264-aq 720p50parkrun.yuv 1280x720 --bitrate 3000 --level 4.1 --
min-keyint 1 --keyint 25 --bframes 0 --ref 1 --weightb --subme 1 --8x8dct --qpmi
n 15 --trellis 0 --nf --me dia --threads auto --partitions all --no-fast-pskip -
-no-dct-decimate --aq-strength 0.4 --progress --sar 1:1 -o parkrun-0.4.mkv

[bob0r]

And with 1 thread?

[CruNcher]

With 1 thread it's ok @ 0.4 allways SSIM Mean Y:0.8448698 @ 12.40 fps
With 2 threads @ 0.4 SSIM changes every run @ 22.62 fps

Seems not threadsafe Dark ;)

[Sagekilla]

Sorry guys, results on Chronicles of Riddick won't be up until tomorrow at the earliest now. I ended up having to standby my computer so I could sleep (Had finals today) so I'm only 20% through the first encode.

[bob0r]

its thread safe, just not non deterministic thread safe.
with or without aq, makes no difference.
pengvado is aware of this issue, and one days hopes to find the cure :)

[Snowknight26]

In the .diff, it says the --aq-strength can go to 1.4 for strong AQ, but in the 1st post you say 1.0. :x

[Dark Shikari]

In the .diff, it says the --aq-strength can go to 1.4 for strong AQ, but in the 1st post you say 1.0. :xI didn't say what it can go to, I just gave examples.

There is technically no limit on how high AQ can go, but after about 2.0-3.0 it will really start to backfire. Perhaps in the help I should say 1.0 is a good medium.

[Sagekilla]

In the .diff, it says the --aq-strength can go to 1.4 for strong AQ, but in the 1st post you say 1.0. :x

1.0 is the recommended setting to use to start with. It gives, on average, very good results. If you read the help, it says 0.7 is "medium" and 1.4 is "stronger."

[chipzoller]

DS, in your original post you mentioned it may not be good for Anime/Cartoon and that you wouldn't use it there. Do you still maintain this, even at AQ's present state?
Is --aq-strength 1.0 a safe-to-use general setting for anime/cartoon if using AQ is advisable?

[Snowknight26]

I didn't say what it can go to, I just gave examples.

Add --aq-strength X to the commandline, where X is a value between 0.0 and 1.0.

Sorry, seemed a little misleading. :p

[Dark Shikari]

DS, in your original post you mentioned it may not be good for Anime/Cartoon and that you wouldn't use it there. Do you still maintain this, even at AQ's present state?
Is --aq-strength 1.0 a safe-to-use general setting for anime/cartoon if using AQ is advisable?Try it... I'm not sure at this point. I haven't done much testing.

If you do testing, post the results.

[Razorholt]

This new AQ seems to darken the picture, am I right?

[Dark Shikari]

This new AQ seems to darken the picture, am I right?AQ has absolutely no affect on image brightness. If it does so, its because your levels are off.

[Sagekilla]

Here's a frame I grabbed from my AQ. (That's still encoding) AQ did a pretty good job at preventing blocking from occurring on the jacket, as you can see. Unfortunately, I'll have to run the encode a third time to possibly increase the strength again. In the second image, you can see some blocking on the light shining in.

http://img.photobucket.com/albums/v621/Sagekilla/Riddick.png

http://img.photobucket.com/albums/v621/Sagekilla/riddick2.png

[DeathTheSheep]

its thread safe, just not non deterministic thread safe.
with or without aq, makes no difference.
pengvado is aware of this issue, and one days hopes to find the cure :)

I have a stopgap cure: don't use threads auto. Use threads=3 if on dual core and threads=6 on quad.

[salehin]

Sagekilla, is it possible for you to share your avs script, encode cmd, & logs. thanks :)

[Sagekilla]

Sagekilla, is it possible for you to share your avs script, encode cmd, & logs. thanks :)

Yes, I'll post my script and settings for now. I have to wait for my encoding to finish before I can post my logs however.


AVS Script
SetMTMode(2,2)
MPEG2Source("source.d2v")
Crop(0,62,0,-66).Spline36Resize(848,352)

# Some light processing, helps x264 compress better.
o = last
b1vec = o.MVanalyse(pel=2,overlap=2,idx=1,delta=1,isb=true)
f1vec = o.MVanalyse(pel=2,overlap=2,idx=1,delta=1,isb=false)
return(o.MVDegrain1(b1vec,f1vec,thSAD=350,idx=2))

x264 Settings
AQ On: x264 --keyint 1000 --crf 18 --ref 4 --mixed-refs --no-fast-pskip --bframes 16 --bime --weightb --b-pyramid --b-rdo --8x8dct --subme 7 --me umh --trellis 1 --aq-strength 1 --threads auto --thread-input --progress --output "videoAQ.264" --pass 1 --stats "stats_AQ.log" "source.avs"

AQ Off: x264 --keyint 1000 --crf 18 --ref 4 --mixed-refs --no-fast-pskip --bframes 16 --bime --weightb --b-pyramid --b-rdo --8x8dct --subme 7 --me umh --trellis 1 --aq-strength 0 --threads auto --thread-input --progress --output "video_NoAQ.264" --pass 1 --stats "stats_NoAQ.log" "source.avs"

Note, I used a long keyint because I don't mind the long latency to decode and I don't seek much to begin with. Change this to something a little more sane (250) if you wish.

[bob0r]

My bad on the nondeterministic issue.
This is only the case with Dark's AQ.

I guess the fixes since 713 also solved the threads issue with different bitrates.

Still as Dark explained AQ + something within x264 code can trigger something nondeterministic.
Guess they have to figure that one out :)


So if any of you got some nondeterministic issue, please report a reproducable method and pengvado will look into it!

[CruNcher]

Yes, I'll post my script and settings for now. I have to wait for my encoding to finish before I can post my logs however.


AVS Script
SetMTMode(2,2)
MPEG2Source("source.d2v")
Crop(0,62,0,-66).Spline36Resize(848,352)

# Some light processing, helps x264 compress better.
o = last
b1vec = o.MVanalyse(pel=2,overlap=2,idx=1,delta=1,isb=true)
f1vec = o.MVanalyse(pel=2,overlap=2,idx=1,delta=1,isb=false)
return(o.MVDegrain1(b1vec,f1vec,thSAD=350,idx=2))

x264 Settings
AQ Off: x264 --keyint 1000 --crf 18 --ref 4 --mixed-refs --no-fast-pskip --bframes 16 --bime --weightb --b-pyramid --b-rdo --8x8dct --subme 7 --me umh --trellis 1 --aq-strength 1 --threads auto --thread-input --progress --output "videoAQ.264" --pass 1 --stats "stats_AQ.log" "source.avs"

AQ On: x264 --keyint 1000 --crf 18 --ref 4 --mixed-refs --no-fast-pskip --bframes 16 --bime --weightb --b-pyramid --b-rdo --8x8dct --subme 7 --me umh --trellis 1 --aq-strength 0 --threads auto --thread-input --progress --output "video_NoAQ.264" --pass 1 --stats "stats_NoAQ.log" "source.avs"

Note, I used a long keyint because I don't mind the long latency to decode and I don't seek much to begin with. Change this to something a little more sane (250) if you wish.

Ehhh you mean AQ ON/AQ OFF? and don't you think those settings are a little insane ;)

[foxyshadis]

Woah, add me to the group. I'm stuck with 681.

Sorry, meant to type DTS.

I get some non-determinism, but it's only in the least-significant two digits of the SSIM. Not something I'm going to worry about.

[chipzoller]

When using CRF mode, is there a threshold one should not go under while using AQ, i.e. what's the lowest CRF that can be used with AQ while still producing helpful results?

[bob0r]

....

I get some non-determinism, but it's only in the least-significant two digits of the SSIM. Not something I'm going to worry about.

With AQ or None AQ?
If you get it with revision 721 SVN, please report a way to reproduce.

[Dark Shikari]

When using CRF mode, is there a threshold one should not go under while using AQ, i.e. what's the lowest CRF that can be used with AQ while still producing helpful results?I don't think there's any. AQ should work well at any bitrate--the only exception to this rule is if the bitrate is so low that the qp_deltas become a considerable portion of the bit cost of the video.