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

[DeathTheSheep]

"major major major major update" = disable auto threshold (in 2pass)? Hmm... ;)

[Dark Shikari]

"major major major major" = disable auto threshold (in 2pass)? Hmm... ;)Major major = remove the limiter when not using automatic thresholding.

I could also make it so that the default sensitivity depends on which pass mode you choose, but for now, set it yourself.

This is the reason why I call it "major major":

http://img255.imageshack.us/img255/2779/sanstitre1rl1.gif

[DeathTheSheep]

Ah, I was wondering when you'd post another one of your aniGifs. Now with contrast enhancement!! But I realize you still forgot to mention what the other two "major"s were for. I have a suggestion: adaptive smexiness profile. ;)

Well, to tell you the truth, I don't see any clear benefit in keeping the limiter--even in auto mode.

[Sagekilla]

Oh curses.. I just started a new encode a few minutes ago, now I have to go check this new update out.

[Dark Shikari]

Ah, I was wondering when you'd post another one of your aniGifs. Now with contrast enhancement!! But I realize you still forgot to mention what the other two "major"s were for. I have a suggestion: adaptive smexiness profile. ;)

Well, to tell you the truth, I don't see any clear benefit in keeping the limiter--even in auto mode.Under the current system, its there for very good reason. This is because if the frame is flat, it'll try to raise the quantizers of the few complex blocks in the frame by a huge amount--causing problems, since it won't lower the blocks in the rest of the frame enough. It *correctly* calculated the *difference* in quantizers between the flat and complex blocks, except that since it wasn't willing to vastly lower the quantizer of the frame, the complex blocks would end up with far too high a quantizer.

[Sagekilla]

Under the current system, its there for very good reason. This is because if the frame is flat, it'll try to raise the quantizers of the few complex blocks in the frame by a huge amount--causing problems, since it won't lower the blocks in the rest of the frame enough. It *correctly* calculated the *difference* in quantizers between the flat and complex blocks, except that since it wasn't willing to vastly lower the quantizer of the frame, the complex blocks would end up with far too high a quantizer.

Hmm just read a few posts up. How come this AQ improvement won't work on CRF?

[lexor]

Automatic thresholding, the default sensitivity option, helps keep the bitrate sane in CRF mode, but in 2pass you can do much better, and use a static sensitivity. Using --aq-sensitivity 30 or similar will result not only in flat areas of individual frames getting more bits, but also entire flat FRAMES getting more bits.
I am a bit confused by that wording. It seems to allow possibility of the entire movie's bitrate going up (if it decides all frames need tuning up, I know unlikely, but as a theoretic possibility). Does it? Dark, you said that that "new" image above is larger, but is it true for the entire movie, or have the bits simply been re-allocated between frames?

[Dark Shikari]

I am a bit confused by that wording. It seems to allow possibility of the entire movies bitrate going up (if it decides all frames need tuning up, I know unlikely, but as a theoretic possibility). Does it? Dark, you said that that "new" image above is larger, but is it true for the entire movie, or have the bit simply been re-allocated between frames?Static sensitivity allows bits to be re-allocated between frames, but gives no guarantee that the bitrate of the movie is anywhere close to that of what you would get without CRF.

It *works* on CRF, but it will not keep the bitrate anywhere near to the original (or at least, one cannot guarantee it).

[lexor]

Static sensitivity allows bits to be re-allocated between frames, but gives no guarantee that the bitrate of the movie is anywhere close to that of what you would get without CRF.

It *works* on CRF, but it will not keep the bitrate anywhere near to the original (or at least, one cannot guarantee it).

Eh, I'm not the guy concerned about CRF, I do 2pass encodes. :)

On that note, will MeGUI's bitrate calculator still be correct (or as correct as it is for official builds)? I mean can I still rely on getting a more or less certain file size out of a 2pass?

[Atak_Snajpera]

It *works* on CRF, but it will not keep the bitrate anywhere near to the original (or at least, one cannot guarantee it).

Hehe It sounds like old Haali's AQ :)

[DeathTheSheep]

Sounds like pretty much anything that redefines the allocation of bits between frames contrary to x264 defaults. :)

[Dark Shikari]

Eh, I'm not the guy concerned about CRF, I do 2pass encodes. :)

On that note, will MeGUI's bitrate calculator still be correct (or as correct as it is for official builds)? I mean can I still rely on getting a more or less certain file size out of a 2pass?Yes, bitrate mode in general (1pass or 2pass) should probably still be pretty accurate at this point.

Slightly less than normal, but not by much.
Sounds like pretty much anything that redefines the allocation of bits between frames contrary to x264 defaults. :)Yup.

It'll be interesting to see what Dakaz thinks of this mode ;)

[Atak_Snajpera]

Dakaz ? Do we know him? :/

[Dark Shikari]

Dakaz ? Do we know him? :/Many don't, but he and the rest of Avail Media's encoding division are behind quite a bit of x264, especially interlaced mode :p

[DeathTheSheep]

He also offered a bounty for people who could produce good, novel x264 code. (http://mailman.videolan.org/pipermail/x264-devel/2007-May/003055.html) And of course by bounty I mean...you know.
Now I just have to cross my fingers and hope the satd patch will come magically rolling in. The guts of this thing are truly, in lack of a better term, mathemagical. (Not to mention easy to break beyond repair, if you don't know what you're doing).

[ToS_Maverick]

Static sensitivity allows bits to be re-allocated between frames, but gives no guarantee that the bitrate of the movie is anywhere close to that of what you would get without CRF.

It *works* on CRF, but it will not keep the bitrate anywhere near to the original (or at least, one cannot guarantee it).

who cares? with Haali's AQ it was clear, that if you enable it, the bitrate with CRF will rise.

i consider it that way: std x264 is not at an optimum.

why do you want to stick to a same frame size? if a frame needs more bits to look good, so be it... as long as the ratecontrol has no problem with it ;)

[Dark Shikari]

who cares? with Haali's AQ it was clear, that if you enable it, the bitrate with CRF will rise.

i consider it that way: std x264 is not at an optimum.

why do you want to stick to a same frame size? if a frame needs more bits to look good, so be it... as long as the ratecontrol has no problem with it ;)Remember what happened with the previous AQ?

Sometimes, video size would rise drastically, other times it would drop drastically.

The point being, that if most of the bits in your video are in blocks that are above the variance threshold you set, your bitrate will drop--and if most of the bits are in blocks that are below, your bitrate will rise.

[slavickas]

He also offered a bounty for people who could produce good, novel x264 code. (http://mailman.videolan.org/pipermail/x264-devel/2007-May/003055.html) And of course by bounty I mean...you know
...
http://upload.wikimedia.org/wikipedia/commons/3/31/BountyBars.jpg
?
edit: my 264 post :D

[Dark Shikari]

I think he means:

http://ecx.images-amazon.com/images/I/51HpkVvqKwL.jpg

[ToS_Maverick]

wait a minute... with a too low --aq-sensitivity xx the bitrate could DROP? well... that's a fact that i didn't know.

my dream of a CRF mode would be, set it at 18 and your encode comes out transparent. if we could reach this goal, we would have a "lame -V2" H264 codec :D

[Dark Shikari]

wait a minute... with a too low --aq-sensitivity xx the bitrate could DROP? well... that's a fact that i didn't know.

my dream of a CRF mode would be, set it at 18 and your encode comes out transparent. if we could reach this goal, we would have a "lame -V2" H264 codec :DThis is because AQ sensitivity sets a midpoint variance, above which the QP is raised, and below which the QP is lowered.

Technically, one could apply the entire "automatic sensitivity" aspect of my algorithm to the ENTIRE VIDEO on the first pass, and then use that sensitivity on the second pass.

[ToS_Maverick]

is my thinking correct:
your auto sensitivity redistributes the bits (lowers/raises quants) from areas that are more complex to lower complex areas.
what's bothering me is, if there is a scene, like the last .gif you posted, where there are no bits to redistribute, what are you going to do?

is there a reliable metric (like ssim), to find out where the problematic parts are, and give them more bits?

of course we could do a lot of testing and tweaking, to find out a good sensitivity that we could use for our encodes, but that would be empirical, and will surely get rejected by aku for SVN...

[Dark Shikari]

is my thinking correct:
your auto sensitivity redistributes the bits (lowers/raises quants) from areas that are more complex to lower complex areas.
what's bothering me is, if there is a scene, like the last .gif you posted, where there are no bits to redistribute, what are you going to do?

is there a reliable metric (like ssim), to find out where the problematic parts are, and give them more bits?

of course we could do a lot of testing and tweaking, to find out a good sensitivity that we could use for our encodes, but that would be empirical, and will surely get rejected by aku for SVN...Sensitivity is arbitrary, in a sense; as long as you don't put a limiter on how QPs are changed.

No matter what sensitivity is chosen, the QPs chosen in a particular frame will be exactly the same, except scaled up or down by a constant value.

[DeathTheSheep]

Hm, it's odd how .45 behaves differently with the same commandline as .431 with the line removed. .431 made the file 4204KB, 0.9747881 SSIM, while your new patch with same threshold made it 4205KB, 0.9747586 SSIM. How did the result become slightly bigger and worse in SSIM, if just the threshold was removed? Maybe change in the code for interlace fixes?

[Dark Shikari]

Hm, it's odd how .45 behaves differently with the same commandline as .431 with the line removed. .431 made the file 4204KB, 0.9747881 SSIM, while your new patch with same threshold made it 4205KB, 0.9747586 SSIM. How did the result become slightly bigger and worse in SSIM, if just the threshold was removed? Maybe change in the code for interlace fixes?There was a slight change to fix a bug when variance was equal to zero.

[DeathTheSheep]

Note to self: you cannot say if(floating point value == 0) before calling x264_cpu_restore()... ;)
http://www.biffleys.com/Strategy/pictures/bounty.jpg

[desta]

Some test results, using AQ with varying thresholds.

--pass 2 --bitrate 4100 --stats "D:\TESTS\test.aq1.sens-auto.stats" --keyint 240 --min-keyint 24 --ref 7 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -3,-2 --subme 7 --trellis 1 --analyse all --8x8dct --vbv-maxrate 25000 --me umh --merange 24 --threads auto --thread-input --progress --no-dct-decimate --output "D:\TESTS\test.aq1.sens-auto.mkv" "D:\TESTS\test.aq1.sens-auto.avs" --aq-strength 1

x264 [info]: slice I:19 Avg QP:17.37 size: 53151 PSNR Mean Y:50.05 U:50.90 V:52.20 Avg:49.86 Global:47.70
x264 [info]: slice P:782 Avg QP:19.27 size: 27715 PSNR Mean Y:45.76 U:48.71 V:49.06 Avg:46.53 Global:46.00
x264 [info]: slice B:519 Avg QP:20.61 size: 10718 PSNR Mean Y:45.11 U:48.61 V:49.06 Avg:45.90 Global:45.07
x264 [info]: mb I I16..4: 21.1% 67.2% 11.7%
x264 [info]: mb P I16..4: 10.4% 30.0% 4.6% P16..4: 24.2% 12.1% 3.2% 0.1% 0.0% skip:15.4%
x264 [info]: mb B I16..4: 2.3% 5.2% 0.9% B16..8: 32.6% 1.9% 4.3% direct: 5.0% skip:47.9%
x264 [info]: 8x8 transform intra:66.2% inter:57.1%
x264 [info]: direct mvs spatial:94.8% temporal:5.2%
x264 [info]: ref P 67.3% 14.7% 6.9% 3.8% 2.9% 2.5% 1.8%
x264 [info]: ref B 76.9% 11.4% 4.6% 2.7% 1.8% 1.5% 1.1%
x264 [info]: SSIM Mean Y:0.9831273
x264 [info]: PSNR Mean Y:45.567 U:48.706 V:49.105 Avg:46.331 Global:45.626 kb/s:4104.32
----------

the following tests use the same options as above, with the only difference being...

--aq-sensitivity 30

x264 [info]: slice I:19 Avg QP:26.11 size: 55517 PSNR Mean Y:49.61 U:50.68 V:51.93 Avg:49.46 Global:46.92
x264 [info]: slice P:782 Avg QP:29.36 size: 27478 PSNR Mean Y:44.90 U:48.13 V:48.45 Avg:45.72 Global:44.85
x264 [info]: slice B:519 Avg QP:30.41 size: 10933 PSNR Mean Y:44.33 U:48.02 V:48.45 Avg:45.17 Global:44.20
x264 [info]: mb I I16..4: 22.6% 63.8% 13.7%
x264 [info]: mb P I16..4: 10.2% 30.8% 5.2% P16..4: 24.9% 11.6% 2.9% 0.1% 0.0% skip:14.4%
x264 [info]: mb B I16..4: 2.7% 5.5% 1.0% B16..8: 33.4% 1.9% 4.4% direct: 4.9% skip:46.3%
x264 [info]: 8x8 transform intra:65.9% inter:54.0%
x264 [info]: direct mvs spatial:93.3% temporal:6.7%
x264 [info]: ref P 67.0% 14.6% 7.0% 3.8% 3.1% 2.6% 1.9%
x264 [info]: ref B 76.2% 11.6% 4.8% 2.8% 1.9% 1.6% 1.2%
x264 [info]: SSIM Mean Y:0.9822634
x264 [info]: PSNR Mean Y:44.746 U:48.122 V:48.500 Avg:45.558 Global:44.605 kb/s:4100.14
----------

--aq-sensitivity 25

x264 [info]: slice I:19 Avg QP:23.89 size: 56126 PSNR Mean Y:49.75 U:50.76 V:52.03 Avg:49.60 Global:47.08
x264 [info]: slice P:782 Avg QP:27.18 size: 27493 PSNR Mean Y:44.97 U:48.15 V:48.49 Avg:45.78 Global:44.93
x264 [info]: slice B:519 Avg QP:28.25 size: 10881 PSNR Mean Y:44.43 U:48.05 V:48.48 Avg:45.21 Global:44.26
x264 [info]: mb I I16..4: 24.6% 62.4% 13.0%
x264 [info]: mb P I16..4: 10.1% 30.9% 5.1% P16..4: 24.8% 11.7% 2.9% 0.1% 0.0% skip:14.4%
x264 [info]: mb B I16..4: 2.6% 5.6% 0.9% B16..8: 33.4% 1.8% 4.4% direct: 4.8% skip:46.4%
x264 [info]: 8x8 transform intra:66.2% inter:54.5%
x264 [info]: direct mvs spatial:93.4% temporal:6.6%
x264 [info]: ref P 67.1% 14.6% 7.0% 3.8% 3.1% 2.6% 1.9%
x264 [info]: ref B 75.9% 11.7% 4.8% 2.9% 1.9% 1.6% 1.2%
x264 [info]: SSIM Mean Y:0.9823568
x264 [info]: PSNR Mean Y:44.825 U:48.149 V:48.536 Avg:45.612 Global:44.677 kb/s:4099.58
----------

--aq-sensitivity 20

x264 [info]: slice I:19 Avg QP:21.63 size: 54153 PSNR Mean Y:49.61 U:50.66 V:51.92 Avg:49.46 Global:47.00
x264 [info]: slice P:782 Avg QP:24.51 size: 27609 PSNR Mean Y:45.04 U:48.20 V:48.53 Avg:45.85 Global:45.03
x264 [info]: slice B:519 Avg QP:25.63 size: 10797 PSNR Mean Y:44.47 U:48.09 V:48.52 Avg:45.27 Global:44.34
x264 [info]: mb I I16..4: 22.9% 64.3% 12.8%
x264 [info]: mb P I16..4: 10.2% 31.0% 5.0% P16..4: 24.8% 11.6% 2.9% 0.1% 0.0% skip:14.4%
x264 [info]: mb B I16..4: 2.6% 5.5% 0.9% B16..8: 33.4% 1.8% 4.4% direct: 4.8% skip:46.7%
x264 [info]: 8x8 transform intra:66.4% inter:55.0%
x264 [info]: direct mvs spatial:93.8% temporal:6.2%
x264 [info]: ref P 67.1% 14.6% 7.0% 3.8% 3.0% 2.6% 1.9%
x264 [info]: ref B 75.9% 11.6% 4.9% 2.8% 1.9% 1.6% 1.2%
x264 [info]: SSIM Mean Y:0.9824983
x264 [info]: PSNR Mean Y:44.883 U:48.192 V:48.573 Avg:45.673 Global:44.765 kb/s:4101.04
----------


Source:
- http://img413.imageshack.us/img413/2694/source66fo1.png
- http://img526.imageshack.us/img526/551/source165am9.png
- http://img526.imageshack.us/img526/1001/source358ij5.png
- http://img237.imageshack.us/img237/3574/source490ut0.png
- http://img242.imageshack.us/img242/9720/source615hn0.png

Auto Sensitivity:
- http://img248.imageshack.us/img248/2976/x264sensauto66iy7.png
- http://img248.imageshack.us/img248/4585/x264sensauto165en5.png
- http://img301.imageshack.us/img301/4273/x264sensauto358is1.png
- http://img99.imageshack.us/img99/6886/x264sensauto490uw8.png
- http://img99.imageshack.us/img99/8848/x264sensauto615el2.png

Sensitivity 30:
- http://img99.imageshack.us/img99/3128/x264sens3066bp5.png
- http://img412.imageshack.us/img412/5105/x264sens30165lw9.png
- http://img262.imageshack.us/img262/4485/x264sens30358rc9.png
- http://img262.imageshack.us/img262/9405/x264sens30490qd9.png
- http://img237.imageshack.us/img237/8185/x264sens30615yt0.png

Sensitivity 25:
- http://img149.imageshack.us/img149/8880/x264sens2566my7.png
- http://img101.imageshack.us/img101/5821/x264sens25165eb6.png
- http://img237.imageshack.us/img237/9567/x264sens25358un8.png
- http://img266.imageshack.us/img266/4593/x264sens25490ad9.png
- http://img101.imageshack.us/img101/6435/x264sens25615rr8.png

Sensitivity 20:
- http://img293.imageshack.us/img293/9208/x264sens2066za7.png
- http://img293.imageshack.us/img293/6128/x264sens20165hv3.png
- http://img293.imageshack.us/img293/7093/x264sens20358hq7.png
- http://img207.imageshack.us/img207/346/x264sens20490ko7.png
- http://img207.imageshack.us/img207/1899/x264sens20615dl4.png

[Dark Shikari]

Interesting results, but it seems there aren't any particularly flat scenes there to test with, as there with some of the earlier sources (where the static sensitivity method did much better).

[DeathTheSheep]

A few comments:
- Perhaps the true power of the AQRC is realized with QP encoding. When it's the only QP-altering force at the helm (rather than x264's rate control, which is shifting quantizers one way as the AQ shifts them the other).
- How about trying 25 instead of either 20 (too low) or 30 (too high, IMHO, at least for my sources/bitrates)?

[Dark Shikari]

A few comments:
- Perhaps the true power of the AQRC is realized with QP encoding. When it's the only QP-altering force at the helm (rather than x264's rate control, which is shifting quantizers one way as the AQ shifts them the other)The issue here is that QP mode doesn't take account into things like the fact that higher QPs can be used right before an I-frame.

[DeathTheSheep]

I'm not so sure that's such a good idea in the first place, especially when you have a lot of I-frames packed into the same place. I frame "flickering" and such become prevalent and distracting...I always hated that in videos. Always. Wonder why I use QP? :p And in anime, such a mechanism is inherently worthless, since any such QP hike is easily noticeable on the static backgrounds/choppy cartoon animations. The purpose of keyframe boost is to raise the quality on I-frames in proportion to surrounding frames (p and especially b), and with your patch, the "smearing" and detail loss (in the form of blurring, sometimes) doesn't occur anyway.
Egh. Maybe that's a rant or something, psht.

[akupenguin]

I'm not so sure that's such a good idea in the first place, especially when you have a lot of I-frames packed into the same place.
Then don't pack lots of I-frames in the same place. There can't be any I-frame flicker if I-frames appear only at scenecuts.
And in anime, such a mechanism is inherently worthless, since any such QP hike is easily noticeable on the static backgrounds/choppy cartoon animations.
Increasing the QP just before an I-frame does absolutely nothing to static backgrounds, because the background has no changes to code at any QP.

[desta]

Interesting results, but it seems there aren't any particularly flat scenes there to test with, as there with some of the earlier sources (where the static sensitivity method did much better).
Well that was primarily why I was testing really. As Sharktooth said earlier, your new AQ really does look like a good reason to completely ditch CQM's. I just wanted to see which sensitivity would yield better overall results, as people aren't typically always going to be encoding from flat/soft/low-detail sources.

- How about trying 25 instead of either 20 (too low) or 30 (too high, IMHO, at least for my sources/bitrates)?
Added test results.

[Sharktooth]

auto still looks better to me.

[Dark Shikari]

The question is, how can we get the benefit of auto while still having good quality in scenes like the two sample images I posted earlier, and the animated GIF?

I could have the ability for auto to limit how low its threshold goes, so as to add more bits to problematic frames... then we could ideally get the best of both worlds.

[DeathTheSheep]

Oops, I meant non-static backgrounds. :) To elaborate, imagine a clip in which the screen is moving (shaking, panning, etc) wherein an animated character does something or an exaggerated motion occurs that triggers a keyframe without actually undergoing a scene change. This is bad enough, but when some aspect of the frame is changing (like the characters move around on the static background), the moving part visibly loses quality against the static, unchanging background. This is an eyesore of sorts if it happens enough, which it seems invariably to do in some anime. And here tweaking the scene change threshold just makes things worse, extending other GOPs to huge numbers of frames and missing actual scene cuts.
If this is an inaccessible example, consider in crf mode when there is an extended sequence of fast but uniform motion (more than even that in CruNcher's clip), and keyframes are inserted during the motion...

Then don't pack lots of I-frames in the same place.
And though that's the goal, those --keyint 9999 users out there are pretty rare, and for good reason.

[Sharktooth]

The question is, how can we get the benefit of auto while still having good quality in scenes like the two sample images I posted earlier, and the animated GIF?

I could have the ability for auto to limit how low its threshold goes, so as to add more bits to problematic frames... then we could ideally get the best of both worlds.
dark masking?

[lexor]

auto still looks better to me.

Actually it seems form desta's images that auto does the best at foreground (faces, etc) and 30 does the best with the backgrounds. Now, if only we could get both... compute the difference between auto calculated value and 30, and bump auto value by half that distance towards 30 (unless it's already higher)? Talking nonsense here.

Of course the problem with those test images is the relatively high bitrate (4mbps), this new AQ would be put to a better test if it was a bit more bitrate starved.

[CruNcher]

People should note that the OLd AQ results http://forum.doom9.org/showthread.php?p=1089048#post1089048 look more visual pleasing in a ABR encode @ 3 Mbit to the eyes (fine edges) then those of the New AQ, as it looses quality there (hard edges) and makes it less watchable (limited or non limited makes no difference).
New AQ in ABR looks almost exactly the same (hard edges) as like in the CRF Encode Shoots (CRF 25).

[DeathTheSheep]

Actually, that might not really be nonsense... I was thinking...

How low can you go, with dark [Shikari] masking.

A best of both worlds approach figuring in automatic sensitivity while still freely giving more bits to frames that need them most, according to the threshold.

Maybe this can be combined with the two-pass mode you mentioned earlier--the first pass would decide on what general threshold to apply to the video in its entirety, and the 2nd pass can apply that threshold in general, yet have the freedom to shuffle bits around elsewhere as well, as would best benefit the video according to the established global threshold and whatever incidental threshold may prove favorable (predictive weighted average)?

[DeathTheSheep]

Wait a minute. When exactly did you address this variance == 0 bug? After 0.431?

[Dark Shikari]

Wait a minute. When exactly did you address this variance == 0 bug? After 0.431?0.45. I have no idea what happened beforehand, but now if variance is zero, it just uses the QP from the previous MB.

[DeathTheSheep]

Simply baffling. I suppose this is testament to the axiom that SSIM, bitrate and such are truly fickle entities indeed.

[Dark Shikari]

News of the day: Not using AQ on your first pass is extremely bad, especially if you're not using adaptive sensitivity.

In other news, water does seem to be somewhat wet and slippery.

[Razorholt]

Would it make sense to use AQ auto in first pass and AQ + sensitivity 30 in second pass - or the other way around?

[Dark Shikari]

Would it make sense to use AQ auto in first pass and AQ + sensitivity 30 in second pass - or the other way around?No, same sensitivity in both passes.

Also, I'd say 30 is probably too high, after some testing.

Maybe 20 or 25.

[Dark Shikari]

Conclusion after encoding a few dozen scenes of The Matrix: static sensitivity 20-25 or so is nearly always better than automatic, but one needs to use the same sensitivity on both passes.

[ChronoCross]

News of the day: Not using AQ on your first pass is extremely bad, especially if you're not using adaptive sensitivity.

In other news, water does seem to be somewhat wet and slippery.

I think the way you put it in the chat room was better.

<Dark_Shikari> also, it turns out
<Dark_Shikari> not using AQ on your first pass
<Dark_Shikari> = EPICFAILURE
<Dark_Shikari> don't do it
<Dark_Shikari> or you might be the next one to join the epic failtrain

[Dreassica]

Is there a way it doesn't work in megui?
I copied the patched x264.exe in the tolls dir, but it wont render anything but if I use the usual settings that do work with standard x264.exe.


This is log from megui:

[Information] Log for job1
-[NoImage] Job type: video
-[Information] [20-1-2008 13:30:29] Started handling job
-[Information] [20-1-2008 13:30:32] Preprocessing
-[NoImage] Job commandline: "G:\Program Files\megui\tools\x264\x264.exe" --qp 16 --ref 16 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter 1,1 --subme 7 --trellis 2 --analyse all --8x8dct --me esa --threads auto --thread-input --sar 1:1 --progress --no-dct-decimate --no-psnr --no-ssim --output "D:\sample.mkv" "D:\\sample.avs" --aq-strength=0.7
-[Information] [20-1-2008 13:30:34] Encoding started
-[Information] [20-1-2008 13:30:34] Job completed


Maybe I'm just stupid and missing something really obvious.

[desta]

Conclusion after encoding a few dozen scenes of The Matrix: static sensitivity 20-25 or so is nearly always better than automatic, but one needs to use the same sensitivity on both passes.
Just as a fyi, those tests I did earlier used the same AQ strength & sensitivity in both passes, and the tests with static sensitivity actually had the quants go up in the 2nd pass.