VAQ 2.0 Alpha Testing

[Dark Shikari]

VAQ 1 is official (http://git.videolan.org/?p=x264.git;a=commit;h=dc4f40ce74c996a1e15021b82ab71ebcb8652d0b), so as I promised, I am releasing VAQ 2.0 for initial alpha testing. Thanks to Alex W for the basic concept behind VAQ 2.0!

How to use (change from normal VAQ):

--aq-metric presents four options for the AQ metric to use. Each is progressively slower than the last; option 0 is equivalent to VAQ1.

Since the VAQ committed to official x264 has 1.0 strength as default (equivalent to 0.5 with unofficial AQ, since all values were doubled for simplicity's sake), 1.0 is default here also.

Try playing with the different AQ metrics and strengths and testing the results.

Download patched build (based on r777) (http://www.mediafire.com/?yyzxvzcz2tm).

[IgorC]

--aq-mode?
Should it be by default fot this time of testing?


Is r777 with VAQ 2.0 multhitreaded? It uses only one core of my e2160 while r798.modified (VAQ 0.48) use 2 cores.

x264_AQ2.exe --threads 3 --pass 3 --progress --stats "x264_stat.log" --qcomp 0.75 --bframes 3 --no-b-adapt --bime --weightb --subme 7 --keyint 300 --ref 8 --trellis 2 --mixed-refs --8x8dct --partitions all --b-rdo --direct auto --b-pyramid --bitrate 2500 --no-fast-pskip --me umh --merange 16 --aq-metric 3 --deblock -1:-1 -o 2xVAQ2_3_Balance2_777.h264 1.avs

[LoRd_MuldeR]

--aq-mode?

--aq-mode <integer> How AQ distributes bits
- 0: Disabled
- 1: Avoid moving bits between frames
- 2: Move bits between frame

I'd guess that "--aq-mode 2" is the default, while "--aq-mode 1" equals "aq-sensitivity 0" in VAQ v0.48

[IgorC]

I know. The question is what to do with it. Leave it or test it?

[LoRd_MuldeR]

I know. The question is what to do with it. Leave it or test it?
Well, unless I have missed something, "--aq-mode 1" (aka "aq-sensitivity 0") is not recommended and "--aq-mode 0" will turn off all AQ.
So I'd go with "--aq-mode 2" unless there is a good to do otherwise...

[Dark Shikari]

Well, unless I have missed something, "--aq-mode 1" (aka "aq-sensitivity 0") is not recommended and "--aq-mode 0" will turn off all AQ.
So I'd go with "--aq-mode 2" unless there is a good to do otherwise...Correct

[MythCreator]

@Dark Shikari

Could you release the diff file of VAQ 2.0? Thanks a lot~

[Dark Shikari]

@Dark Shikari

Could you release the diff file of VAQ 2.0? Thanks a lot~The code is extremely ugly and the diff won't work on any recent revision of x264. Anyone who publicly distributes builds of this with any intent other than to experiment is crazy.

diff (http://pastebin.com/f5034219f)

[Selur]

two side questions:
1. What in the value range allowed for --aq-strength?
2. Does --aq-strength 0.0 also disable adaptive quantization?

Cu Selur

Ps.: there's a 'new-line' missing before '--nr' (after metric options) when calling --long-help ;)

[Dark Shikari]

two side questions:
1. What in the value range allowed for --aq-strength?
2. Does --aq-strength 0.0 also disable adaptive quantization?
AQ strength = 0 to infinity (though values above 2.0 may get stupid).

AQ strength = 0 = disabled.

Exactly the same as the AQ in the official x264.

[Selur]

Thanks for the Info. :)

Cu Selur

[MasterNobody]

For those who are interested here (http://stashbox.org/97383/x264_vaq2_alpha.diff) is diff which can be applied on the current git version (r808). Also I fix bug in x264_autosense_aq (incorrect use of h->mb.i_mb_x and h->mb.i_mb_y instead of mb_x and mb_y)

[bob0r]

Warning: ALPHA BUILD, ONLY USE FOR TESTING VAQ2!

x264.808.vaq2.modified.exe (http://files.x264.nl/VAQ2/x264.808.vaq2.modified.exe) (gcc 3.4.6 fprofiled)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264_vaq2_alpha.01.r808.diff
http://forum.doom9.org/showthread.php?p=1120023#post1120023
x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.6.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3550
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919

Link to x264 patches collected: http://files.x264.nl/x264_patches/

Warning: ALPHA BUILD, ONLY USE FOR TESTING VAQ2!

[Umamio]

Here is a collection of tests I did on a couple of 4 second football clips. They are slightly worthless for comparison purposes because they are mostly different framesizes and different bitrates and CQ / 2pass / 3pass whatever.

The only thing they have in common is they all use VAQ2 (using patched build based on r777)! Unless specified.

So if you want a collection of slightly useless (for comparative purposes) encodes of football on a rainy imperfect pitch you can get them here (http://www.mediafire.com/?t1mgyltzkti).

Better comparisons in here (http://forum.doom9.org/showthread.php?p=1120492#post1120492)

[DeathTheSheep]

Excellent job, MasterNobody. Thou art truly the master o'er bugs, o BugMaster. :)

I will certainly give this a test soon. How is the speed on BugMaster's mod? Does it do the same thing as the original on 777?

[DeathTheSheep]

The answer appears to be yes on both fronts.

I made a test on my quintessential anime clip.
0.46 yields 0.9741681 SSIM 4537KB
2.0a yields 0.9710652 SSIM 4557KB (--aq-strength 2 --aq-metric 3)
2.0a yields 0.9724646 SSIM 4546KB (--aq-strength .3 --aq-metric 3)

Baseline profile, defaults, no fast pskip.

[Razorholt]

The answer appears to be yes on both fronts.

I made a test on my quintessential anime clip.
0.46 yields 0.9741681 SSIM 4537KB
2.0a yields 0.9710652 SSIM 4557KB (--aq-strength 2 --aq-metric 3)

Ah. Baseline profile, defaults, no fast pskip,

What's your --aq settings with 0.46?

[DeathTheSheep]

Updated post.

Settings with 0.46 were strength 1.1, sens 24.5. Of course with better settings and keyframe tweaks (since DS found problems near keyframes in my past 46vs47 tests), SSIM can go up to .9752XXX easily with 0.46. With qcomp active for anime, even more still.

[edit] But by goodness that's not to say 0.46 is better than 2.0!! Just that for this clip, for these settings, at this bitrate, for this material, SSIM is higher.

[Dark Shikari]

The answer appears to be yes on both fronts.

I made a test on my quintessential anime clip.
0.46 yields 0.9741681 SSIM 4537KB
2.0a yields 0.9710652 SSIM 4557KB (--aq-strength 2 --aq-metric 3)
2.0a yields 0.9724646 SSIM 4546KB (--aq-strength .3 --aq-metric 3)

Baseline profile, defaults, no fast pskip.Please stop poisoning my development threads with your totally useless comparisons that:

1) Do not include no-AQ numbers.
2) Only include values for one metric, and with two wildly varying strengths with nothing sane in between.

:rolleyes:

P.S. SSIM is not that useful. SSIM tells me that AQ mode 1 is better than 2, which it isn't.

[Razorholt]

@DS:

1.- Is there any minimum birates required for VAQ2 to be efficient?
2.- How can we compare different settings if SSIM is irrelevant?
3.- What is the --aq mode/metric/strength default in VAQ2?


Thanks a lot DS for your great job!

- Dan

[Dark Shikari]

@DS:

1.- Is there any minimum birates required for VAQ2 to be efficient?I don't really know yet.
2.- How can we compare different settings if SSIM is irrelevant?SSIM isn't necessarily irrelevant, but its not always useful. The best judge is always your eyes.
3.- What is the --aq mode/metric/strength default in VAQ2?Mode=2, Metric=3, Strength=1.

[DeathTheSheep]

DS: You could've just asked for the non-AQ number, some strengths in between, and/or some PSNR's. I'd be only too happy to oblige. It somehow gives off a nicer impression than calling something poison. :)

[Dark Shikari]

DS: You could've just asked for the non-AQ number, some strengths in between, and/or some PSNR's. I'd be only too happy to oblige. It somehow gives off a nicer impression than calling something poison. :)Okay, so I was a little harsh :p It just seems like you intentionally ignored the most obvious settings, and chose ones way far to the sides. :)

[ToS_Maverick]

i did a short test @CRF 22 and got these results:

VAQ1 0.9716895
VAQ2 0.9727707

VAQ2 was slightly better visually too. at CRF 20 there is only a very slight difference, which i think is also true for CRFs below 20

[Encoder888]

I apologize for my dumb questions in advance, as I'm not as experienced with AQ as you are:

So, in VAQ2, the sensitivity option is eliminated, right? Since mode should almost always be set on 2, in order to even have the AQ on, then all you can really adjust is the strength and the metric right? So, I take it the strength works the same way as before, the higher, the better the quality. And the metric? From what I got from your posts, you can only adjust it from 0 - 6, and so, is it the higher the metric, the better the quality? What exactly does the metric do? Is it like sensitivity in the previous VAQ, or was that mode...? Thanks for reading my stupid question :)

[Dark Shikari]

I apologize for my dumb questions in advance, as I'm not as experienced with AQ as you are:

So, in VAQ2, the sensitivity option is eliminated, right? Since mode should almost always be set on 2, in order to even have the AQ on, then all you can really adjust is the strength and the metric right? So, I take it the strength works the same way as before, the higher, the better the quality. And the metric? From what I got from your posts, you can only adjust it from 0 - 6, and so, is it the higher the metric, the better the quality? What exactly does the metric do? Is it like sensitivity in the previous VAQ, or was that mode...? Thanks for reading my stupid question :)The metric is the method of calculating which blocks get what quantizer. Its a mathematical formula.

[cogman]

So VAQ uses metricies to attempt to give better results correct? I thought part of the purpose of VAQ 1 was to eliminate the need for metricies (cqm). So is the some major fundamental difference between the terms?

Also, given that differing metricies give different results, is the quality difference going to be somewhat of a constant (IE Matrix one gives better quality then matrix two, but with a slower encode)? Or is this going to be a guess and check sort of solution to picking which matrix to encode with.

Just curious.

[Dark Shikari]

So VAQ uses metricies to attempt to give better results correct? I thought part of the purpose of VAQ 1 was to eliminate the need for metricies (cqm). So is the some major fundamental difference between the terms?A matrix has nothing to do with a metric. They're about as related as a beaver and a muon.

[cogman]

A matrix has nothing to do with a metric. They're about as related as a beaver and a muon.

lol, ok, I guess I was just mixing up terms. Thanks for the responce.

Though, is there going to be a fairly standard quality gain/loss with the use of different metrics? or will it just depend video to video?

[Umamio]

Source:
Football Clip - 720x576 (16:9) - 25fps interlaced - Huffyuv
Smartbobbed & Resized - 688x384 - 50fps - Huffyuv [ Download Here (79.3MB) (http://www.mediafire.com/?jjfzmzrex4j) ]
Duration: 6s (331 frames)

x264 build:
x264.808.vaq2.modified.exe (gcc 3.4.6 fprofiled)
[ http://files.x264.nl/VAQ2/x264.808.vaq2.modified.exe ] [ http://forum.doom9.org/showthread.php?p=1120033#post1120033 ]

x264 args:
--pass 2 --bitrate 1284* --stats ".stats" --ref 3 --bframes 16 --b-pyramid --weightb --direct auto --filter -2,-1 --subme 6 --trellis 1 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --merange 12 --aq-strength (variable:[0.5,1,1.5,2,2.5]) --aq-metric (variable:[0,1,2,3])

*1284k/50frames == 642k/25frames

Encodes:

Metrics 0(VAQ1.0),1,2,3 * Strengths 0.5,1.0,1.5,2.0,2.5
+ VAQ off (Strength 0, Metric 0)
[ Download Here (22.85MB, 21 files zipped) (http://www.mediafire.com/?izzzwxjxdma) ]


Single Frame Comparison (VAQ off Vs. Metric 3 Strength 1 Vs. Metric 3 Strength 1.5 Vs. Metric 3 Strength 2 Vs. Source):

http://thumbnails.freeimagehost.eu/291/8fd4c82908457.gif (http://www.freeimagehost.eu/image/8fd4c82908457)
(click to enlarge)

I only have PSNR and SSIM numbers for the metric 3 encodes and with VAQ off, but you can see from the files that there is a clear visual improvement without looking at the values (I haven't seen the logs yet)

For this specific type of high... grass source at least the optimal Strength seems to be between 1.3 and 2.2, I'm still staring at these trying to compare the metrics but there might not be enough fine detail in my source to make an accurate judgement using this material.

Conclusion: VAQ loves grass sports and I love VAQ.

Edit:


Some PSNRSSIMnumberstuff:
VAQ Off:
SSIM Mean Y:0.9087551
PSNR Mean Y:33.601 U:40.486 V:41.777 Avg:34.978 Global:34.571 kb/s:1377.74

Metric 3 - Strength 0.5
SSIM Mean Y:0.9157095
PSNR Mean Y:33.513 U:40.607 V:41.806 Avg:34.904 Global:34.598 kb/s:1387.76

Metric 3 - Strength 1.0
SSIM Mean Y:0.9233749
PSNR Mean Y:33.339 U:40.752 V:41.876 Avg:34.751 Global:34.409 kb/s:1385.98

Metric 3 - Strength 1.5
SSIM Mean Y:0.9265114
PSNR Mean Y:32.728 U:40.651 V:41.664 Avg:34.173 Global:33.816 kb/s:1369.50

Metric 0 - Strength 1.5
SSIM Mean Y:0.9256282
xPSNR Mean Y:33.066 U:40.626 V:41.715 Avg:34.488 Global:34.161 kb/s:1379.88

Metric 3 - Strength 2.0
SSIM Mean Y:0.9226995
PSNR Mean Y:31.642 U:40.306 V:41.231 Avg:33.132 Global:32.750 kb/s:1357.14

Metric 0 - Strength 2.0
SSIM Mean Y:0.9247225
PSNR Mean Y:32.291 U:40.411 V:41.386 Avg:33.749 Global:33.420 kb/s:1366.41

Metric 3 - Strength 2.5
SSIM Mean Y:0.9108505
PSNR Mean Y:30.138 U:39.825 V:40.674 Avg:31.679 Global:31.292 kb/s:1347.17

Disclaimer: I mostly don't know what I am talking about or what I am doing, so I advise you to not trust any of this and do try things out for yourself.

[ToS_Maverick]

you shouldn't forget, VAQ uses qcomp of 1.0 while the standard x264 setting is 0.6.

the bottom line is, with qcomp 0.6, fast motion (like football) doesn't get as much bitrate as i would need. please try 1.0 without AQ, that would be interesting. maybe that's a reason why AQ looks so much better.

[Terranigma]

you shouldn't forget, VAQ uses qcomp of 1.0 while the standard x264 setting is 0.6.

the bottom line is, with qcomp 0.6, fast motion (like football) doesn't get as much bitrate as i would need. please try 1.0 without AQ, that would be interesting. maybe that's a reason why AQ looks so much better.

You sure you know what you're talking about? According to x264 --longhelp, qcomp's default is now 1.0.
(Well, from the build I grabbed.)

[Dark Shikari]

You sure you know what you're talking about? According to x264 --longhelp, qcomp's default is now 1.0.
(Well, from the build I grabbed.)That's because AQ is on by default ;)

[Umamio]

you shouldn't forget, VAQ uses qcomp of 1.0 while the standard x264 setting is 0.6.

Ah you're right, I forgot about qcomp getting changed but in this clip it doesn't seem to make very much difference at all when I set it to 1. QAV off, Qcomp-1, Download (1.11MB) (http://www.mediafire.com/?c2lmg3bxhdj)
8275

I'm interested in seeing the best that I can get out of x264 for football without using QAV to make it a better (but less fair) comparison, do you have any suggestions for other parameters I could change?

[ToS_Maverick]

That's because AQ is on by default ;)

well does it revert back to 0.6 if you switch it off?

[Dark Shikari]

well does it revert back to 0.6 if you switch it off?It did in the patch I gave to pengvado... you can check pretty easily by looking at the header of the output H.264 file to see if he kept it that way.

[Tack]

Conclusion: VAQ loves grass sports and I love VAQ.
The first thing I noticed was how much worse the BBC logo was in the bottom (VAQ) image.

No doubt though that the grass is much better. I suppose one could make a fairly solid argument that VAQ is causing the bits to be spent in the right places.

[Umamio]

The first thing I noticed was how much worse the BBC logo was in the bottom (VAQ) image.

No doubt though that the grass is much better. I suppose one could make a fairly solid argument that VAQ is causing the bits to be spent in the right places.

If you look at the logo in any of the encodes (http://www.mediafire.com/?izzzwxjxdma) with strengths < 1.5 the logo and score suffer a lot less with not much of a loss in grass detail.

I only tested in strength steps of 0.5 so it's likely that I missed the VAQ strength "sweet spot" for this particular video but that's for another day. This post was really just to illustrate the variations of the different strengths and metrics. It's likely that the quality could be improved with a little more bitrate and more focussed small-step strength testing but the differences may not be as noticeable if the algorithm has lots of bits to spare.

If you encode something at a stupidly low bitrate with a stupidly high VAQ and compare it to the same thing encoded at the same stupidly low bitrate with vaq turned off you can really see the types of detail that VAQ focusses its bits on.

Actually, I will do that for you (http://www.mediafire.com/?wtyacgyxjcy). But make sure you look at the regular stuff before you look at these extreme/stupid examples or it might affect your judgement. :)

P.S: I could be wrong about everything I just said.

[Dark Shikari]

Edit:


Some PSNRSSIMnumberstuff:
VAQ Off:
SSIM Mean Y:0.9087551
PSNR Mean Y:33.601 U:40.486 V:41.777 Avg:34.978 Global:34.571 kb/s:1377.74

Metric 3 - Strength 0.5
SSIM Mean Y:0.9157095
PSNR Mean Y:33.513 U:40.607 V:41.806 Avg:34.904 Global:34.598 kb/s:1387.76

Metric 3 - Strength 1.0
SSIM Mean Y:0.9233749
PSNR Mean Y:33.339 U:40.752 V:41.876 Avg:34.751 Global:34.409 kb/s:1385.98

Metric 3 - Strength 1.5
SSIM Mean Y:0.9265114
PSNR Mean Y:32.728 U:40.651 V:41.664 Avg:34.173 Global:33.816 kb/s:1369.50

Metric 0 - Strength 1.5
SSIM Mean Y:0.9256282
xPSNR Mean Y:33.066 U:40.626 V:41.715 Avg:34.488 Global:34.161 kb/s:1379.88

Metric 3 - Strength 2.0
SSIM Mean Y:0.9226995
PSNR Mean Y:31.642 U:40.306 V:41.231 Avg:33.132 Global:32.750 kb/s:1357.14

Metric 0 - Strength 2.0
SSIM Mean Y:0.9247225
PSNR Mean Y:32.291 U:40.411 V:41.386 Avg:33.749 Global:33.420 kb/s:1366.41

Metric 3 - Strength 2.5
SSIM Mean Y:0.9108505
PSNR Mean Y:30.138 U:39.825 V:40.674 Avg:31.679 Global:31.292 kb/s:1347.17Interesting that the optimal strength for SSIM is so high...

[DeathTheSheep]

A really interesting thing happened to me with this.

While using CQP of 30 for the original and modeling the strength around it to produce similar sized files (since there's no sensitivity any more for 1-pass bitrate fine-tuning!!), 0.46 is much better (see my post on the first page of this thread). Only strength 2 and 0.3 were close enough to the original filesize, but even with a larger filesize, strength 1.0's ssim was pretty low compared to the AQ 0.46. ALL aq tested then were better than the non-AQ SSIM.

BUT. Here's the interesting part. In 2-pass vbr, there is MUCH LESS DIFFERENCE between the various forms of AQ for the sample at target bitrate 400kbps (size ~4155KB). See the results below, all AQ using mode 3 for now:
NO AQ: 0.9702865, PSNR: 37.043-o36.709
NO AQ(qcomp1): 0.9672502, PSNR: 36.844-o36.397
st 0.5: 0.9692864, PSNR: 36.553-o36.010
st 1.0: 0.9693076, PSNR: 35.846-o35.166
st 1.5: 0.9660272, PSNR: 34.648-o33.833
st 2.0: 0.9576726, PSNR: 32.911-o31.958
0.46, st 1.0, sens 16: 0.9705006, PSNR: 36.159-o34.722.264

As you can see, the SSIM hardly rises at all (in fact it falls for every AQ strength other than 0.46).

I don't usually use 2-pass mode, preferring a target quality rather than an exact filesize. This is why I haven't done much testing in this area.

I do think (like another member has pointed out), that either sensitivity needs to be re-implemented (preferably, since I get very different results using sens 16 and sens 25 at the same filesize for aq 0.46), or allow decimal QP/CRF to be specified.

[edit]AH, forgot to mention. Clip is same one as I used/gave you before.
Commandline was: x264 test.avs -o out.264 --aq-strength {x} --aq-metric 3 --no-fast-pskip --no-cabac -A all --thread-input --me umh --pass 2 --bitrate 400 {--qcomp 1} --keyint 1500

[Umamio]

Interesting that the optimal strength for SSIM is so high...

My theory is that because over 80% of the pixels in this clip make up grass, and because the detail in the grass is so faint, even if I destroyed all the foreground stuff with massive strength the SSIM would still be relatively high so the SSIM penalty for smashing foreground detail is lower than it would be for something more normal, like a film or TV series.

Maybe.

[Dark Shikari]

since I get very different results using sens 16 and sens 25 at the same filesize for aq 0.46)If this is the case, its a bug. I will begin reading your posts again if you can pinpoint the source of this bug.

I'm serious here; I noticed this a while back, and it really shouldn't be the case. If you can find me the reason in the code why varying sensitivity can potentially change the quantizer distribution significantly in twopass mode, that would be quite useful...

[woah!]

VAQ48 = SSIM Mean Y:0.9810858 8.17 fps, 5415.96 kb/s

VAQ 0 = SSIM Mean Y:0.9811255 8.47 fps, 5440.41 kb/s

VAQ 1 = SSIM Mean Y:0.9812286 8.21 fps, 5427.13 kb/s

VAQ 2 = SSIM Mean Y:0.9815481 7.89 fps, 5432.41 kb/s

VAQ 3 = SSIM Mean Y:0.9815457 7.10 fps, 5431.28 kb/s

VAQ 4 = SSIM Mean Y:0.9815457 7.20 fps, 5431.28 kb/s



all using strength 1.2

i used a clip from Day after Tomorrow bluray 1080p not resized or anything at a bitrate of 5550 2 pass. all other settings are what i always use for my hd-dvd compatible authoring. the scene is 4 mins in where they are coring for samples and the crack in the ice sheet starts to open up...

[Umamio]

VAQ 3 = SSIM Mean Y:0.9815457 7.10 fps, 5431.28 kb/s

VAQ 4 = SSIM Mean Y:0.9815457 7.20 fps, 5431.28 kb/s

all using strength 1.2


I thought there were only 4 metrics: 0, 1, 2, 3
I suspect your metric 3 and metric 4 files may be identical!
What SSIM do you get with --aq-strength 0 --qcomp 1?


0.46, st 1.0, sens 16: 0.9705006, PSNR: 36.159-o34.722.264


Can I get the 0.46 build you're using to test it for funky behaviour with my non-anime footballisms?

[DeathTheSheep]

DS: Wait, so you don't read my posts?? And yet you yell at me anyway? :( (ps: post edited with more details like you wanted before).

Anway. The sensitivity "bug" is probably not confined to a line in the algo itself, but rather to the nature of the algo and ratecontrol. It likely stems from the fact that when the AQ lowers/raises everything's quant at a different threshold while ratecontrol is given the same bitrate to work with, it makes decisions differently. I doubt it's limited to the algorithm alone--if the bug is confined to it, I certainly wouldn't know where to look. I hardly even use 2pass, much less know how x264's rate control works.

But the problem thickens. Try using constant quantizer. CQ X -sens Y at bitrate B is slightly different than CQ (X-lambda) -sens (y+-lambda') at same bitrate B.

One thing to do with it is the keyframes, perhaps. I know boosting the ipratio at CQ X can effectively raise SSIM when sens Y is adjusted to maintain B, but the same keyframe boost trick with CQ x-lambda doesn't raise SSIM at all, in practice. Perhaps this is due to the fact that x264 simply lowers keyframe quantizers (or raises B-frame quantizers) by an integer value of factor 1.4 times the p frame quant. If you specify QP 30, the I frames could be at 27, whereas if you specify QP 15, I would be 12, etc, all at different bitrates, all with different sizes and SSIMs of their own, even after the total bitrate is re-leveled with a new sensitivity.

Maybe the same argument applies to B-framez. Maybe we can test the QP hypothesis at least by forcing all ratios to 1.0 then comparing the two. QP30 -sens 25, QP29 -sens 21 give me the same sizes with .46 (after a bit of adjustment), so go figure.

PS: According to the rounding, 0.46 is by definition "funky behavior." I am a fan of funky music though. Go figure! One such build can be found here (http://forum.doom9.org/showpost.php?p=1120419&postcount=916). A bit dated, though.

[Umamio]

I am a fan of funky music though. Go figure!

Play that funky mUUuusic white boooooooy

:thanks:

[woah!]

source is The Rock bluray AVC 1080p original file bitrate 31858 kbps.


VAQ48 = SSIM Mean Y:0.9568357 4.06 fps, 16119.15 kb/s

VAQ 0 = SSIM Mean Y:0.9566338 4.09 fps, 15905.28 kb/s

VAQ 1 = SSIM Mean Y:0.9563507 4.10 fps, 15795.36 kb/s

VAQ 2 = SSIM Mean Y:0.9569956 3.96 fps, 16092.06 kb/s

VAQ 3 = SSIM Mean Y:0.9571898 3.83 fps, 16151.72 kb/s


all default VAQ2 settings, just metric changed - CRF26

result screenshots in a pack ... http://www.smalllinks.com/46G

[IgorC]

Seems like VAQ 2 uses more advanced algorithms than based on SSIM purely. I just wanted to mention (W)CWSSIM. It's more reliable metric than simple SSIM. Are some kind of these metrics used in new VAQ?

Here is already well known paper about WCWSSIM http://www.ece.northwestern.edu/~pappas/papers/brooks_hvei06.pdf

[Avenger007]

I tested 3 non-anime clips containing short distance (>30% of frame area) to closeups of face and body with a fair amount of skin shown. Thus, I'm testing how well VAQ handles little facial and skin details given that skin tone has a gradient and usually results in blurring of details and blocking on large skin areas.

Clip 1
This clip has 3 camera angle changes of the same people.

Settings:
avis : 352x288 @ 25.00 fps (865 frames)

--pass 2 --bitrate 500 --ref 16 --mixed-refs --no-fast-pskip --bframes 8 --b-pyramid --b-rdo --bime --weightb --direct auto --subme 7 --trellis 2 --partitions all --8x8dct --me umh --merange 32 --threads auto --thread-input --sar 1:1 --progress --no-psnr --sar 12:11 --aq-metric [0, 1, 3] --aq-strength [0.75, 1, 1.25]

strength 0
SSIM 0.9855646

strength 0.75
metric 0: SSIM 0.9861316
metric 3: SSIM 0.9864114

strength 1
metric 0: SSIM 0.9861450 4.2% improvement over VAQ off
metric 1: SSIM 0.9863353
metric 3: SSIM 0.9864244 6.3% improvement over VAQ off

strength 1.25
metric 0: SSIM 0.9861327
metric 3: SSIM 0.9862227


Clip 2
This clip has only one camera angle with minimal background movement.

Settings:
avis [info]: 512x384 @ 29.97 fps (327 frames)

Same as Clip 1 except:
--bitrate 800 --keyint 300 --min-keyint 30 --sar 1:1

strength 0
SSIM 0.9786412

strength 0.75
metric 0: SSIM 0.9799664
metric 3: SSIM 0.9803084

strength 1
metric 0: SSIM 0.9802144 8.0% improvement over VAQ off
metric 3: SSIM 0.9803256 8.6% improvement over VAQ off

strength 1.25
metric 0: SSIM 0.9799985
metric 3: SSIM 0.9801740


Clip 3
This clip also has only one camera angle but shows a closeup of face and body with camera moving up and down and zooming in and out slowly.

Settings:
avis [info]: 512x384 @ 29.97 fps (2461 frames)
Same as Clip 2.

strength 0
SSIM 0.9850764

strength 0.75
metric 0: SSIM 0.9853343 1.8% improvement over VAQ off
metric 1: SSIM 0.9855772
metric 3: SSIM 0.9856469 4.0% improvement over VAQ off

strength 1
metric 0: SSIM 0.9852713 1.3% improvement over VAQ off
metric 1: SSIM 0.9854063
metric 3: SSIM 0.9855809 3.5% improvement over VAQ off

strength 1.25
metric 0: SSIM 0.9851264
metric 3: SSIM 0.9851633


Observations (My eyes only :eek:):
For strength 1, metric 3 gives better quality than metric 0.

For strength 1.25, metric 3 may give better quality than metric 0.
However, I noticed in some frames that very small areas of skin between skin-background borders seem to extend slightly beyond the border and cover the background, but these artifacts are hard to spot. Maybe this sort of "bleeding" of color caused the lower SSIM. Thus, metric 0 gives better quality in these clips for strength 1.25.
Strength 1.25 kept more detail (less blurring) on textured parts of skin and face than strength 1.

Lower strength values (0.75) generally don't seem to help much.
In clip 3, the outfit worn is latex (I think) and causes lots of sharp borders between skin and clothes. It also has "curves of brightness", i.e. creases and folds are brightly lit as opposed to gradient color of flat areas. It seems like aliasing artifacts are occurring, so lower strength results in higher SSIM.
It's hard to tell which metric was better at which strength for clip 3 since each combination improved some parts while making other parts look worse.


Well that took a while to type, I hope it's helpful and not too long :)

P.S. I used TemporalDegrain on the source to remove noise and improve compressibility resulting in pre-rendered clips which were used for encoding.

[I]Disclaimer:
Since I don't know how VAQ works, I don't know what to look for and what to overlook.

[burfadel]

Just a VAQ related question, does VAQ organise the distribution of bits as is, or is it a reallocation of bits from another process?

[Razorholt]

@Avenger007: Can you please include the file size?

Thanks,
- Dan

[Avenger007]

@Avenger007: Can you please include the file size?

Thanks,
- Dan

Clip 1:
huffyuv: 43,212KB
Encoded: 2,151KB +- 3KB

Clip 2:
huffyuv: 31,145KB
Encoded: 1,099KB +- 3KB

Clip 3:
huffyuv: 221,532KB
Encoded: 8,076KB +- 8KB

[Sagittaire]

Warning: ALPHA BUILD, ONLY USE FOR TESTING VAQ2!

x264.808.vaq2.modified.exe (http://files.x264.nl/VAQ2/x264.808.vaq2.modified.exe) (gcc 3.4.6 fprofiled)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264_vaq2_alpha.01.r808.diff
http://forum.doom9.org/showthread.php?p=1120023#post1120023
x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.6.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3550
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919

Link to x264 patches collected: http://files.x264.nl/x264_patches/

Warning: ALPHA BUILD, ONLY USE FOR TESTING VAQ2!

build completely buggy ... produce very bad quality and completely different result if I compare with Dark Shikary build.

[Avenger007]

build completely buggy ... produce very bad quality and completely different result if I compare with Dark Shikary build.

Do you mind giving some figures to elaborate on "very bad quality and completely different result"? :sly:

I used the alpha build for the results I posted. :cool:

[Poopoo]

Didn't Dark Shikari say that higher SSIM values don't really guaranty a better encoding ?

[Blue_MiSfit]

That's always true. Stuff like AQ and RDO tend to lower metrics, but they usually improve subjective quality. Tricky to evaluate! :)

~MiSfit

[CruNcher]

Hmm Dark is it normal that with your 777 AQ test build Multithreading doesn't work? (AMD64) and with bob0rs it works?

[Dark Shikari]

Hmm Dark is it normal that with your 777 AQ test build Multithreading doesn't work? (AMD64) and with bob0rs it works?Yes, my pthreads broke again and I'm too lazy to fix it

[Razorholt]

Can someone please confirm that there is no visual difference between mode=0 and mode=1 (whatever strength you set).

Compare pictures (http://70.86.69.186/~matrix2/compare.php)

x264
--pass 2 --bitrate 640 --stats ".stats" --keyint 14 --min-keyint 2
--deadzone-inter 10 --deadzone-intra 6 --ref 5 --mixed-refs
--no-fast-pskip --bframes 16 --b-pyramid --b-rdo --bime --weightb
--direct auto --subme 7 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct
--vbv-maxrate 25000 --qcomp 0.55 --me esa --merange 32 --threads auto
--thread-input --progress --no-dct-decimate


EDIT: Image comparison page updated for better use. Should I include SSIM?

Thanks,
- Dan

[Dark Shikari]

Can someone please confirm that there is no visual difference between mode=0 and mode=1 (whatever strength you set).Mode=0 is also known as off. :p

Just leave it on mode 2 for now!

[Razorholt]

Yes, I was aware of mode=0 being the off switch. Apparently, so is mode=1 :D

ooookay... mode=2 it is. :)

[Avenger007]

@DS:
Is there a range for quality factor (bits per pixel) that VAQ1 and VAQ2 tend to work best?
Also, is there any artifacts I can look for to tell if the qf I'm using is too low?

[Dark Shikari]

@DS:
Is there a range for quality factor (bits per pixel) that VAQ1 and VAQ2 tend to work best?
Also, is there any artifacts I can look for to tell if the qf I'm using is too low?"Quality factor" (BPP) is a basically meaningless measure. I would avoid using it for any purpose.

[Avenger007]

I speculated as much. I'm guessing it's because bitrate distribution is far from being evenly distributed across the frame even without VAQ.
But what about my second question, are there any artifacts in particular that I can look for to suggest I'm using too low bitrate for VAQ to work effectively?

[Dark Shikari]

I speculated as much. I'm guessing it's because bitrate distribution is far from being evenly distributed across the frame even without VAQ.
But what about my second question, are there any artifacts in particular that I can look for to suggest I'm using too low bitrate for VAQ to work effectively?There is no real thing as "too low a bitrate" for VAQ; VAQ will start failing at the same sort of bitrates x264 in general fails at.

[Razorholt]

@DS: I noticed no difference between Trellis 1 and Trellis 2when VAQ is on. Could it be due to VAQ, somehow?

Look at Image 8 (Trellis1) vs. Image 9 (Trellis2) (http://70.86.69.186/~matrix2/compare.php)


Thanks,
- Dan

[Dark Shikari]

@DS: I noticed no difference between Trellis 1 and Trellis 2when VAQ is on. Could it be due to VAQ, somehow?

Look at Image 8 (Trellis1) vs. Image 9 (Trellis2) (http://70.86.69.186/~matrix2/compare.php)


Thanks,
- DanOdd.

I would be surprised if I broke trellis with VAQ2. :p

[burfadel]

The picture looks the same, is the file size & SSIM the same? In this case it is an accurate comparison, as same data=same numbers! The Trellis 2 file in CRF should be fractionally smaller? The header of the file may change I believe, but the change in header alone won't change the output filesize.

[Razorholt]

The picture looks the same, is the file size & SSIM the same? In this case it is an accurate comparison, as same data=same numbers! The Trellis 2 file in CRF should be fractionally smaller? The header of the file may change I believe, but the change in header alone won't change the output filesize.

I used 2 Pass but I'll try with CRF later.

Trellis1
x264 [info]: SSIM Mean Y:0.9790550
x264 [info]: PSNR Mean Y:43.634 U:48.093 V:49.790 Avg:44.499 Global:41.274 kb/s:643.04

encoded 3433 frames, 2.59 fps, 643.66 kb/s
desired video bitrate of this job: 640 kbit/s - obtained video bitrate (approximate): 645 kbit/s

Trellis2
x264 [info]: SSIM Mean Y:0.9794983
x264 [info]: PSNR Mean Y:43.761 U:48.219 V:49.940 Avg:44.628 Global:41.405 kb/s:643.12

encoded 3433 frames, 2.34 fps, 643.74 kb/s
desired video bitrate of this job: 640 kbit/s - obtained video bitrate (approximate): 645 kbit/s

[Razorholt]

Is it me or on the screenshot 2 (http://70.86.69.186/~matrix2/compare.php?ss=2) the No AQ looks better? :confused:

[Avenger007]

Is it me or on the screenshot 2 (http://70.86.69.186/~matrix2/compare.php?ss=2) the No AQ looks better? :confused:

Yes, that appears true. All I can say is: try a lower strength or look at frames close to it.

[Razorholt]

Yes, that appears true. All I can say is: try a lower strength or look at frames close to it.

Didn't you mention earlier that "Lower strength values (0.75) generally don't seem to help much.".

Anyway, I'm encoding @ strength=0.5 and strength=0.75 as you suggested. Let's see...

[Dark Shikari]

Is it me or on the screenshot 2 (http://70.86.69.186/~matrix2/compare.php?ss=2) the No AQ looks better? :confused:AQ has a tendency to move bits between frames. As a result, single-frame comparisons are often totally worthless.

[Avenger007]

So does lower strength translate into less bits moved across frames or is there no significant correlation?

[Razorholt]

OK! My bad on Trellis... it was a glitch :D

I also uploaded Previous/Next Frames: check again (http://70.86.69.186/~matrix2/compare.php?ss=2)

[burfadel]

That make sense, since the PSNR & SSIM are higher, hence that actual data stream is different with your Trellis 2 settings!

[stax76]

In case anybody is looking for a GUI, StaxRip has now AQ controls.

http://forum.doom9.org/showthread.php?p=1121319#post1121319

http://planetdvb.net/non_drupal/forum_images/greenshot_2008-04-04_14-12-24.png

[Sharktooth]

Under Rate control? Wrong place or name. It should be (in) Quantization.

[stax76]

It's under rate control documented. :confused:

[Sharktooth]

Maybe coz it actually "moves bits". Well, then i guess it's ok to leave it under rate control.

[Razorholt]

Yes, that appears true. All I can say is: try a lower strength or look at frames close to it.

Check the Image 7 and Image 8 (http://70.86.69.186/~matrix2/compare.php?ss=2)for lower strength.

The No AQ (Image 1) still looks better to me :( - Even by comparing the close frames. Why is that?

[IgorC]

Compare frame to frame is useless.

Why?

AQ has a tendency to move bits between frames. As a result, single-frame comparisons are often totally worthless.

[Avenger007]

Check the Image 7 and Image 8 (http://70.86.69.186/~matrix2/compare.php?ss=2)for lower strength.

The No AQ (Image 1) still looks better to me :( - Even by comparing the close frames. Why is that?
I really don't know :confused:. In my clips, VAQ off resulted in noticeably blurred textured details on the skin (but then again some blurred images looked visually a little better (less unnecessary/noise-like detail) than the original, go figure :D).
However, your No AQ image has a lot more textured detail than the VAQ2 ones.
I also tested metric=0 and compared it with the original, which did give slightly better quality over metric=3 for strength>1 contradicting SSIM in some clips, but that was relatively rare and not the norm. So that's the only advice I can offer.

Also, could it be that the jpg screenshots are loosing too much detail? Just a thought. :p

Compare frame to frame is useless.
Would you mind telling us how to go about doing this testing? :rolleyes:
Playing (30 fps) through some of the encoded clips hardly shows noticeable differences as opposed to, say, a football clip. ;)

[Razorholt]

Also, could it be that the jpg screenshots are loosing too much detail?

If this is the case it shouldn't reverse the results. I'm currently running another batch with CRF 24 instead of 2 Pass. Let's see how it goes.

[IgorC]

Would you mind telling us how to go about doing this testing? :rolleyes:
Playing (30 fps) through some of the encoded clips hardly shows noticeable differences as opposed to, say, a football clip. ;)

If you don't see those artifacts then why care about it?

I can see artefacts even after high block +2:+2. But I wouldn't use +2:+2. During playback I don't see artefacts that I see watching 1 frame per minute. They are 24-30 frames per second. (each frame by 1/30 sec = 0,033 sec = 33 msec each frame). Would you spot artefacts on that speed?
That is all about psy AQ (VAQ in this case). Balance between artefacts/blur and detail for real playback.

blind ABX is a good method to compare. Unique usefull? More probably.

[patrick_]

I'm not sure if I should post this here or in a StaxRip thread, but it's directly related to AQ.

I'm compressing an anime (from DVD) 22:15 minutes. It's an old anime. The image shakes a little, but there's hardly any noise.
I use staxrip compressibility check to set quality at 55%.

I've tried with x264 build 736 (so no AQ) and build 807 @ AQ 1.5. If AQ uses more bits in flat areas, the same 55% should requiere a higher bitrate shouldn't it?

Numbers:
0.0 AQ 1230 bps
1.0 AQ 1211 bps (-1,46%)
1.5 AQ 1028 bps (-16,4%)
2.0 AQ 883 bps (-28,2%)

It's hard to tell (subjectively) which one has better quality. In certain areas it's AQ 0.0 in others it's AQ 1.5 (I didn't compress at 1.0 or 2.0)

screenshots (AQ 0.0 and 1.5):
1A (http://www.megadescarga.es/mi1.png)
1B (http://www.megadescarga.es/mi2.png)

2A (http://www.megadescarga.es/mi3.png)
2B (http://www.megadescarga.es/mi4.png)

In my opionion AQ 0.0 is sharper.
AQ 0.0 and 1.5 block in certain areas, but different ones.
Shades are better at 0.0 (strange, because AQ should improve shades).

I guess I'm missing something about the influence of AQ on the filesize, and I hope someone can help me out.

[Deinorius]

It would be much better, if you compare at equal bitrates.

From your source (and the pictures you posted) my conclusion is, that you get nearly same quality with about 15 % less bitrate which means: You can use the same bitrate (as without AQ) or a lower crf value (Constant Quality) to get a better quality.

[patrick_]

I've used a lot StaxRip, and in my experience quality > 55% isn't worth it. I compress my DVDs to take the videos with me and because harddisk space is limited, I care a lot about filesize. So I'm looking for a way to maintain quality, while reducing size.

[Inventive Software]

OK guys, once I've finished my current encode, I'm gonna thrash the Elephants Dream SD source through both the current x264 trunk and x264 VAQ2 enabled.

Plan is: all partitions, 8x8dct, hadamard (tesa), subme 7, 16 bframes, 16 refs, b-optimizations, trellis 1, direct auto, me-prepass and no-fast-pskip. Target bitrate is 500 Kbits 2 pass, and I'll post the PSNR and SSIM values from both encodes. Any suggestions as to what else is useful/not useful? Any as to what I can throw away that won't affect quality for the first pass?

[Inventive Software]

(Note: AQ settings were the defaults for each build.)


VAQ1 (revision 808 trunk, x264.nl) x264 settings

Pass 1: --bitrate 500 --pass 1 --bframes 16 --ref 16 --subme 3 --partitions none --me dia --merange 32 --direct auto --8x8dct --mixed-refs --me-prepass --b-rdo --weightb --b-pyramid --bime --trellis 1 --stats "ED500KbpsVAQ1.stats" --threads 3 --progress --output "P1VAQ1.264" "Elephants Dream.avs"

Pass 2: --bitrate 500 --pass 3 --bframes 16 --ref 16 --subme 7 --partitions all --me tesa --merange 32 --direct auto --8x8dct --mixed-refs --me-prepass --b-rdo --weightb --b-pyramid --bime --trellis 1 --stats "ED500KbpsVAQ1.stats" --threads 3 --progress --output "Elephants Dream 500 Kbps VAQ1.mp4" "Elephants Dream.avs"


VAQ2 (revision 808 trunk + VAQ2 patch, x264.nl, download (http://forum.doom9.org/showthread.php?p=1120033#post1120033)) x264 settings

Pass 1: --bitrate 500 --pass 1 --bframes 16 --ref 16 --subme 3 --partitions none --me dia --merange 32 --direct auto --8x8dct --mixed-refs --me-prepass --b-rdo --weightb --b-pyramid --bime --trellis 1 --stats "ED500KbpsVAQ2.stats" --threads 3 --progress --output "P1VAQ2.264" "Elephants Dream.avs"

Pass 2: --bitrate 500 --pass 3 --bframes 16 --ref 16 --subme 7 --partitions all --me tesa --merange 32 --direct auto --8x8dct --mixed-refs --me-prepass --b-rdo --weightb --b-pyramid --bime --trellis 1 --stats "ED500KbpsVAQ2.stats" --threads 3 --progress --output "Elephants Dream 500 Kbps VAQ2.mp4" "Elephants Dream.avs"


No AQ (revision 808 trunk, x264.nl, same as the VAQ1 build)

Pass 1:--bitrate 500 --pass 1 --bframes 16 --ref 16 --subme 3 --partitions none --me dia --merange 32 --direct auto --8x8dct --mixed-refs --me-prepass --b-rdo --weightb --b-pyramid --bime --trellis 1 --aq-mode 0 --stats "ED500KbpsNoAQ.stats" --threads 3 --progress --output "P1NoAQ.264" "Elephants Dream.avs"

Pass 2: --bitrate 500 --pass 3 --bframes 16 --ref 16 --subme 7 --partitions all --me tesa --merange 32 --direct auto --8x8dct --mixed-refs --me-prepass --b-rdo --weightb --b-pyramid --bime --trellis 1 --aq-mode 0 --stats "ED500KbpsNoAQ.stats" --threads 3 --progress --output "Elephants Dream 500 Kbps No AQ.mp4" "Elephants Dream.avs"


2nd Pass SSIM Mean (According to x264)

VAQ1: 0.9741147, no AQ delta: 0.0009015

VAQ2: 0.9741536, no AQ delta: 0.0009404

No AQ: 0.9732132


2nd Pass PSNR Mean (According to x264)

VAQ1: Y: 41.588, U: 54.541, V: 54.094, Avg: 42.742, Global: 40.737, kb/s: 500.49, no AQ Global delta: -0.457

VAQ2: Y: 41.318, U: 54.578, V: 54.174, Avg: 42.487, Global: 40.416, kb/s: 500.46, no AQ Global delta: -0.778

No AQ: Y: 43.303, U: 54.978, V: 54.363, Avg: 44.375, Global: 41.194, kb/s: 500.74


Download links

No AQ: http://rapidshare.com/files/106110969/Elephants_Dream_500_Kbps_No_AQ.mp4

VAQ1: http://rapidshare.com/files/106111590/Elephants_Dream_500_Kbps_VAQ1.mp4

VAQ2: http://rapidshare.com/files/106112192/Elephants_Dream_500_Kbps_VAQ2.mp4

I will upload the videos in the morning so you can see for yourself. Screenshots are pretty useless, since VAQ works by shifting bits between frames. ;) Also metrics can only tell you so much. ;) The AviSynth script loads the Lagarith lossless-encoded PNG original multiple image source. I chose Lagarith partly because of speed, but mostly because it decodes quickly, and is lossless (duh).

Now, if you'll pardon me, I need sleep before I suffer burnout. Please wait until morning (roughly 8 hours) for a reply from anything remotely making sense. :D Any more different encodes you'd like with different AQ settings, please state which settings you want, and I'll set it to go whilst I'm at uni. :)

Update 9th April: PSNR and SSIM results are up! :) They appear to show that VAQ2 is slightly better at the job. ;)

I did find it's slower though, the first pass for VAQ2 took 10.37 fps compared to 11.57 fps for VAQ1, and the second pass for VAQ2 was 1.23 fps compared to 1.24 fps for VAQ1. "No AQ" was fastest overall, first pass was 12.59 fps, second pass was 1.27 fps. Those are x264's reported values, I'll calculate what it actually was later on when I've had substantially more caffeine. :D Videos will be uploaded to Rapidshare so you can see for yourself. :)

I hope this is helpful, Dark Shikari. I've wanted to do this since this popped into the forum just before the holidays. :D

2nd Update 9th April: Videos are uploaded. :) Please download and compare, as I can't seem to spot any difference between VAQ2 and VAQ1. No AQ looks a little fuzzy.

[IgorC]

Inventive Software, talking about your encodes:

The most pronounced difference between VAQ and No AQ that I could noticed was during period between 4:12 and 4:47.
For me VAQ 1 and 2 did better job than No AQ (on monotone and soft gradients structures like light emitions ). I hardly can say which VAQ is better.

[MasterNobody]

For those who interested I create the modification of VAQ2 in which I try to optimize some parameters of AQ.

Changes from original VAQ2:
- added aq-mode = 3 (hybrid of modes 1 and 2); dynamic aq-sensitivity which is calculated by algorithm similar to aq-mode = 1 but for all already encoded frames (not only the current frame), this results that at first it is close to aq-mode = 1 but more frames it encodes more close it becomes to aq-mode = 2
- remove dependence of qcomp from aq-strength (more flexibility of qcomp option gives greater possibilities for optimizations)
- disable AQ in CQP mode (it contradicts to title of the mode)
- retrieve aq-sensitivity option; its meaning is same but range of possible values was changed (I recommend to keep it in range from 6 to 12); it is used only in aq-mode = 2; for calculation of new aq-sensitivity from old you can use this function: <new aq-sensitivity> = ln(<old aq-sensitivity>^4 / 2)
- change default values of AQ options:
* decrease aq-strength from 1.0 to 0.6
* set aq-sensitivity equal to 10 (original VAQ2 use value about 8.5)
* set aq-mode equal to 3 instead of 2
* don't change aq-metric (keep it equal to 3)
- remove warning about using new AQ metrics
- other small or cosmetic changes in code

Here is diff (http://stashbox.org/103931/x264_vaq2mod.01.r821.diff).

[MythCreator]

x264.821.vaq2.modified.experimental.exe (http://www.fs2you.com/files/da20d414-0cd1-11dd-bb5d-00142218fc6e/)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264_vaq2mod.01.r821.diff
http://forum.doom9.org/showthread.php?p=1126723#post1126723
x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.7.diff
http://thread.gmane.org/gmane.comp.video.x264.devel/3093/focus=3748
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.php?p=1047919#post1047919
x264_fix_win_stdin.diff
http://forum.doom9.org/showthread.php?p=1120065#post1120065

Link to x264 patches collected: http://files.x264.nl/x264_patches/



make frofiled in GCC 4.4.0 20080331 experimental,totally for experiment & test

[CruNcher]

@MasterNobody
That sounds really good especially loosing the chain of qcomp from it sounds like AQ 0.46 on steroids
tough i quiet don't understand (* don't change aq-metric (keep it equal to 3)) 3 is bloody slow and unusable in production yet and the visual gain is questionable vs the speed lose @ the moment compared to 1 :D

[Razorholt]

@MasterNobody: You fixed --aq-mode 1 ?

[Razorholt]

hmm... I just tried vaq2mod.01 with GrainOptimizer (thanks again Darky) and I got this:

http://69.46.26.197/~doompics/razorholt/images/snapshot20080418103824.bmp


It was OK with the previous version of VAQ2 tho.

EDIT: I used --aq-mode 3



Thanks,
- Dan

[MasterNobody]

hmm... I just tried vaq2mod.01 with GrainOptimizer (thanks again Darky) and I got this:

http://69.46.26.197/~doompics/razorholt/images/snapshot20080418103824.bmp


It was OK with the previous version of VAQ2 tho.

EDIT: I used --aq-mode 3



Thanks,
- Dan

AQ couldn't cause such artifacts (it only changes QP for whole macroblock, but on your image artifacts are only in part of macroblocks [one pixel-height lines]), so I think this bug is caused by something else (possible variants: other patches, changes from 808 to 821, compiler error, GrainOptimizer [I don't know how it works and could it cause such artifacts], other AviSynth filters)

@MasterNobody: You fixed --aq-mode 1 ?If you mean my comment about x264_autosense_aq here (http://forum.doom9.org/showthread.php?p=1120023#post1120023) than yes.

[Razorholt]

@MythCreator: Can you please release a version with both x264_vaq2mod.01.r821.diff and the new FGO patch from Darky -as well as the usual diffs?


Thanks a lot!

- Dan

[DeathTheSheep]

With the exception of disabling VAQ in CQP mode, I think that AQ bugmaster mod has some good ideas.

CruNcher, you mentioned it was like "0.46 on steroids;" care to elaborate a bit?

[MasterNobody]

With the exception of disabling VAQ in CQP mode, I think that AQ bugmaster mod has some good ideas.
I disable AQ in CQP because of 3 things:
1) it contradicts to the title of the mode: Constant QP
2) in CQP mode min and max QP (which also used for limitation of AQ macroblocks QP) are limited by --ipratio and --pbratio (not --qpmin and --qpmax) and so for I-frames AQ could only increase QP for some macroblocks and for B-frames it could only decrease QP
3) for same result you can use CRF with --qcomp 1 (which gives bit-identical result without AQ, and with AQ it doesn't have limitations described in item 2).

[MasterNobody]

Update VAQ2mod patch to the latest x264 revision (826) also make changes similar to revision 826 AQ changes (AQ now treats perfectly flat blocks as low energy, rather than retaining previous block's QP. fixes occasional blocking in fades)
VAQ2mod diff (http://stashbox.org/106755/x264_vaq2mod.02.r826.diff)
VAQ2mod + FGO diff (http://stashbox.org/106756/x264_vaq2mod_fgo.01.826.diff) (and here is FGO for original x264: FGO for standard VAQ diff (http://stashbox.org/106757/x264_fgo.01.826.diff))

And here is x264 CLI build: x264_826bm_VAQ2mod.exe (http://stashbox.org/106764/x264_826bm_VAQ2mod.exe)

GCC --version: (GCC TDM-2 for MinGW) 4.3.0
yasm --version: 0.6.2.1985

Configuration:
Platform: X86
System: MINGW
avis input: yes
mp4 output: no
pthread: yes
gtk: no
debug: no
gprof: no
PIC: no
shared: no
visualize: no
fprofiled: no

Used patches:
x264_vaq2mod_fgo.01.826.diff
x264_fix_win_stdin.diff
Updated versions of my patches from here (http://mailman.videolan.org/pipermail/x264-devel/2008-January/003921.html):
* 32x32samples_crash.diff
* cosmetic.diff
* debug-defines.diff
* fix_stats_file_work_for_cli.diff
* frames_memoryleak.diff
* multithreading_Nth_pass_ratecontrol.diff
* thread-pool.diff

All in one of above patches: x264_all_in_one.diff (http://stashbox.org/106771/x264_all_in_one.diff)

[DeathTheSheep]

Is it intentional that AQ interferes with keyframe placement in crf mode? I always get a keyframe at frame 26 (that's right after the min interval of 25) even though there obviously should be no scene cut there (and isn't without aq).

mode 2, metric 3, thres 10. Strength 1.0 and 1.5 tried.

[Dark Shikari]

Is it intentional that AQ interferes with keyframe placement in crf mode? I always get a keyframe at frame 26 (that's right after the min interval of 25) even though there obviously should be no scene cut there (and isn't without aq).

mode 2, metric 3, thres 10. Strength 1.0 and 1.5 tried.AQ can change keyframe placement in unthreaded mode, because non-threaded scenecut decision depends on the relative ratios of inter and intra costs in encoding.

[DeathTheSheep]

Well, it's quite ugly, whatever it is. You see slow, smooth motion, and then BAM the whole screen suddenly flickers, all the details/textures change slightly. Looks like a bad flash video from dailymotion...XD

By the way, it doesn't happen with strength 0.9 and below, only 1.0 and up. Sens. doesn't matter.

[nicko]

Infortunately with small delay ( MasterNobody already has uploaded b839bm_ VAQ2mod http://sourceforge.net/project/showfiles.php?group_id=213809 ) but the essence does not change.

The small comparative test for х264vfw _ 819bm _ VAQ2mod (high motion sample)

1.Setup from official bild by definition: aq-sensitivity=8.517...

--aq-strength 1 --aq-sensitivity 8.52 --aq-mode 2 --aq-metric 3 --qcomp 1 , crf=26.0

SSIM, PSNR, file size
0.9603961, 39.066, 596 450 bytes

2. Strength=0.6 from 819bm _ VAQ2mod by definition.
--aq-strength 0.6 --aq-sensitivity 10.85 --aq-mode 2 --aq-metric 3 --qcomp 1 , crf=29.0

SSIM, PSNR, file size
0.9600517, 39.415, 595 141 bytes

3.Mode-3 from 819bm _ VAQ2mod by definition.
--aq-strength 1 --aq-mode 3 --aq-metric 3 --qcomp 1 , crf=28.0

SSIM, PSNR, file size
09603382, 39.057, 595 281 bytes

4. Strength=0.6 and Mode-3 from 819bm _ VAQ2mod by definition.
--aq-strength 0.6 --aq-mode 3 --aq-metric 3 --qcomp 1 , crf=28.0 (measured AQ sensitivity: 9.8160)

SSIM, PSNR, file size
09604333, 39.465, 601 610 bytes

5. Strength=0.6 from 819bm _ VAQ2mod by definition, qcomp=1.2.
--aq-strength 0.6 --aq-sensitivity 9.78 --aq-mode 2 --aq-metric 3 --qcomp 1.2 , crf=30.0

SSIM, PSNR, file size
0.9603223, 39.459, 596 343 bytes

6. Strength=0.7, qcomp=1.2.
--aq-strength 0.7 --aq-sensitivity 8.94 --aq-mode 2 --aq-metric 3 --qcomp 1.2 , crf=30.0

SSIM, PSNR, file size
0.9604363, 39.377, 595 459 bytes

The size was fitted with the help of - aq-sensitivity and/or crf.



As it is visible from the tests, the main advantage of MasterNobody version - capability to change aq-sensitivity and not only...

[DeathTheSheep]

DS (or BM), any updates on this? Is the broken keyframe insertion fixed? Any quality optimizations?

[Dark Shikari]

Not really... VAQ 2.0 is only marginally better, overly slow, and there are more pressing issues IMO.

[DeathTheSheep]

QNS? (cavlc needs a boost...badly)

[IgorC]

There is experimental compilation from komisar666 (from another forum):
x264.851mod.pf.e11ef38.exe (http://komisar.gin.by/fl/x264.851mod.pf.e11ef38.exe)

x264.851mod.i686.pf.e11ef38.exe (http://komisar.gin.by/fl/x264.851mod.i686.pf.e11ef38.exe) (fprofiled, -march=i686)
x264.851mod.i586.pf.e11ef38.exe (http://komisar.gin.by/fl/x264.851mod.i586.pf.e11ef38.exe) (fprofiled, -march=i586)
x264.851mod.k8.pf.e11ef38.exe (http://komisar.gin.by/fl/x264.851mod.k8.pf.e11ef38.exe) (fprofiled, -march=k8)
x264.851mod.k6.pf.e11ef38.exe (http://komisar.gin.by/fl/x264.851mod.k6.pf.e11ef38.exe) (fprofiled, -march=k6)

x264.851mod.i686.nopf.e11ef38.exe (http://komisar.gin.by/fl/x264.851mod.i686.nopf.e11ef38.exe) (NO-fprofiled, -march=i686)
x264.851mod.i586.nopf.e11ef38.exe (http://komisar.gin.by/fl/x264.851mod.i586.nopf.e11ef38.exe) (NO-fprofiled, -march=i586)
x264.851mod.k8.nopf.e11ef38.exe (http://komisar.gin.by/fl/x264.851mod.k8.nopf.e11ef38.exe) (NO-fprofiled, -march=k8)
x264.851mod.k6.nopf.e11ef38.exe (http://komisar.gin.by/fl/x264.851mod.k6.nopf.e11ef38.exe) (NO-fprofiled, -march=k6)

gcc version 4.4.0 20080508 (experimental) (GCC)
yasm 0.7.0.2066

Configuration:
Platform: X86
System: MINGW
avis input: yes
mp4 output: yes
pthread: yes
gtk: no
debug: no
gprof: no
PIC: no
shared: no
visualize: no

Used patches:
010.x264_fix_win_stdin.diff
020.32x32samples_crash.diff
030.cosmetic.diff
040.debug-defines.diff
050.fix_stats_file_work_for_cli.diff
060.frames_memoryleak.diff
070.multithreading_Nth_pass_ratecontrol.diff
080.x264.gaussian.cplxblur.01.diff
090.x264_hrd_pulldown.04_interlace.diff
100.x264_me-prepass_DeathTheSheep.01.diff
110.x264_2pass_vbv.8.diff
120.x264_fgo.2_vaq2mod.02.r826.diff
999.x264_cosmetic_stdout.diff

make fprofiled

[Quark.Fusion]

What is current status of VAQ 2.0, is it integrated, in development or stalled/abandoned?

[Dark Shikari]

What is current status of VAQ 2.0, is it integrated, in development or stalled/abandoned?Too slow, not enough better to bother.

There's more interesting things to work on in the area of RD and quantization.

[Quark.Fusion]

Will it be here later as insane (like ESA) option?

[Weltall]

Hello, my megui just updated xvid_encraw from svn to svn+vaq. I tried to read and understand this thread, but I could only read :)

Could someone explain me what vaq means, and if I, like a normal encoder using megui, should bother with some new configurations, or this is enabled by default? What will change and what I have to change myself?

Thanks.

Edit.: I am very sorry, when I updated my megui, x264 and this file were also updated, then I thought they were linked, I didnt notice xvid part on the name, it was a total lack of attention... :p

Nevermind, sorry for this. I wish I could delete this comment :(

Thanks for your answer, anyway.

[nm]

This thread is about x264 VAQ 2, so you'll probably want to look here instead: http://forum.doom9.org/showthread.php?t=135093

[MasterNobody]

Here is new VAQ2mod patch: http://stashbox.org/149221/x264_vaq2mod.04.r892.diff

Changes from previous VAQ2mod:
- Added new aq-metric 4 (which is fast as aq-metric 0 and have SSIM-quality near aq-metric 3)
- Make aq-metric 4 default aq-metric
- Return default aq-strength to 1.0

[MythCreator]

x264.892.vaq2mod.exe (http://www.fs2you.com/files/267525cc-4724-11dd-aeb5-00142218fc6e/)


General thread:
http://forum.doom9.org/showthread.php?t=130364

X264_progress.indication.diff
http://forum.doom9.org/showthread.php?t=135905
x264_qpfile_relax.diff(fixed)
http://forum.doom9.org/showthread.php?p=1151919#post1151919
x264_interlaced_signaling.r886.diff
http://mailman.videolan.org/pipermail/x264-devel/2008-June/004656.html
x264_vaq2mod.04.r892.diff
http://forum.doom9.org/showthread.php?p=1153982#post1153982


Link to x264 patches collected: http://files.x264.nl/x264_patches/


GCC 3.4.5 build fprofiled

[Razorholt]

This build crashed MeGUI twice... humm. I'll try again tomorrow morning.

[Quark.Fusion]

Here is new VAQ2mod patch: http://stashbox.org/149221/x264_vaq2mod.04.r892.diff

Changes from previous VAQ2mod:
- Added new aq-metric 4 (which is fast as aq-metric 0 and have SSIM-quality near aq-metric 3)
- Make aq-metric 4 default aq-metric
- Return default aq-strength to 1.0

What about bitrate at --crf with this --aq-strength?

[Dark Shikari]

At first glance, AQ-metric 4 is mathematically equivalent to metric 0 except for the fact that it naturally contains a larger multiple--in other words, equivalent to raising the AQ strength by some value.

Its also slightly slower; it misses the entire reason why AQ was implemented in the way it was originally.

[MasterNobody]

Dark Shikari
You are right that metric 4 is slightly changed metric 0 and that it is not use overlapped window (in fact the only change to metric 0 needed to make it metric 4 is to fill flat[16] with zeros and not 128). But you are wrong that the same effect can be achieved by raising aq-strength. As I understand metric 4 fix "bug" (in my opinion) of metric 0, which doesn't exist in metric 3 (and probably that is why it was better and not due the overlapped window).
Here is example of this "bug". Lets we encode macroblock with size 8x8 with such values (256 of course couldn't be in byte value, but I use it to simplify calculations; you may replace 256 with 255 and 0 with 1 the result would be similar):
256, 256, 256, 256, 000, 000, 000, 000
256, 256, 256, 256, 000, 000, 000, 000
256, 256, 256, 256, 000, 000, 000, 000
256, 256, 256, 256, 000, 000, 000, 000
000, 000, 000, 000, 256, 256, 256, 256
000, 000, 000, 000, 256, 256, 256, 256
000, 000, 000, 000, 256, 256, 256, 256
000, 000, 000, 000, 256, 256, 256, 256
Or such macroblock:
256, 000, 256, 000, 256, 000, 256, 000
000, 256, 000, 256, 000, 256, 000, 256
256, 000, 256, 000, 256, 000, 256, 000
000, 256, 000, 256, 000, 256, 000, 256
256, 000, 256, 000, 256, 000, 256, 000
000, 256, 000, 256, 000, 256, 000, 256
256, 000, 256, 000, 256, 000, 256, 000
000, 256, 000, 256, 000, 256, 000, 256
How metric 0 would calculate energy for it:
ssd = (256-128)^2*32+(0-128)^2*32 = 128^2*64 = 2^20
sad = |256-128|*32+|0-128|*32 = 128*64 = 2^13
energy = ssd - (sad * sad / 64) = 2^20 - (2^13 * 2^13 / 64) = 2^20 - (2^26 / 2^6) = 2^20 - 2^20 = 0

And here how "fixed" metric 0 (equal to metric 4) would calculate it:
ssd = (256-0)^2*32+(0-0)^2*32 = 256^2*32 = 2^21
sad = |256-0|*32+|0-0|*32 = 256*32 = 2^13
energy = ssd - (sad * sad / 64) = 2^21 - (2^13 * 2^13 / 64) = 2^21 - (2^26 / 2^6) = 2^21 - 2^20 = 2^20

Big difference isn't it? I don't think this can be explained by simple large multiple. Also I don't think it was intended behavior of metric 0.

I don't say that such values in macroblocks are regular, but such examples show that the difference between metric 0 and metric 4 is more than you think.

Here is patch http://stashbox.org/150320/x264_vaq2mod.05.r892.diff (don't use. it has overflow bug) which calculates metric 4 as metric 0 (results will be slightly different from previous metric 4) with above described fix (so it has same speed as metric 0)
it misses the entire reason why AQ was implemented in the way it was originally.
Why?

[Dark Shikari]

This is not a bug in AQ, but rather in Akupenguin's implementation of it. My original implementation simply used an array of zeroes for flat (IMO the correct way to do it).

The flat array was changed to 128s for the purpose of eliminating the potential SAD*SAD overflow, which exists in your latest posted patch and existed in my original also.

My point was that the purpose of the way the AQ implementation was designed was to avoid a typical variance calculation by not doing a memset.

[MasterNobody]

Dark Shikari
Yes, you right about overflow (probably I need go sleep to clear my mind). And why using of memset is so bad (speed lose is not so big as for example metric 3)?

[Dark Shikari]

Dark Shikari
Yes, you right about overflow (probably I need go sleep to clear my mind). And why using of memset is so bad (speed lose is not so big as for example metric 3)?It isn't bad at all, its just that if you have a mathematically equivalent way to do things while avoiding the memset, why not? :p

[MasterNobody]

Dark Shikari
I think more and now think there is now real overflow here. Because the maximum sad = 255*256 = 65280 = 0xFF00 and so sad*sad = 4261478400 = 0xFE010000 which fit in unsigned int without overflow. And than we use SHR command (not SAR if would use singed int) so there result of (sad*sad >> 8) fit in signed integer normally.

[nicko]

But you kept the strength constant, completely ignoring what I said.
So, now like you want, case with variable strength, 750 frames, 704x528, high motion:

strength-1, sensitivity-9.1, metric-4
x264vfw [info]: SSIM Mean Y:0.9610814
x264vfw [info]: PSNR Mean Y:36.716 U:39.914 V:40.946 Avg:37.613 Global:37.359 kb/s:867.40


strength-1.4398 sensitivity-9.1, metric-0
x264vfw [info]: SSIM Mean Y:0.9596083
x264vfw [info]: PSNR Mean Y:36.447 U:39.744 V:40.758 Avg:37.362 Global:37.117 kb/s:870.37

In this case metric 4 even better....

[Dark Shikari]

Dark Shikari
I think more and now think there is now real overflow here. Because the maximum sad = 255*256 = 65280 = 0xFF00 and so sad*sad = 4261478400 = 0xFE010000 which fit in unsigned int without overflow. And than we use SHR command (not SAR if would use singed int) so there result of (sad*sad >> 8) fit in signed integer normally.You're right.

It turns out Akupenguin can't actually remember why he made the array an array of 128s. Either way, this is a silly bug and the fix is going in today. Thanks for the report.

[Dark Shikari]

Fixed, though it took a few hours to hunt down a nasty GCC bug relating to alignment on win32 before I could commit it.

[Razorholt]

Great news because I like VAQ2 :) Will we see a build with both VAQ2+PsyRDO soon?

Thanks,
- Dan

[LoRd_MuldeR]

Fixed, though it took a few hours to hunt down a nasty GCC bug relating to alignment on win32 before I could commit it.
:thanks:

Can you estimate how critical the recent VAQ fix is? Using a build before the fix, what would be the effect in a "real life" encode?

I ask because I encoded a lot of videos with x264 since VAQ was added...

[Dark Shikari]

:thanks:

Can you estimate how critical the recent VAQ fix is? Using a build before the fix, what would be the effect in a "real life" encode?

I ask because I encoded a lot of videos with x264 since VAQ was added...Not too big a deal; the bug only slightly decreases the effectiveness of VAQ as a whole.

[nicko]

Not too big a deal; the bug only slightly decreases the effectiveness of VAQ as a whole.

Yes, for my tests with metric 4 (at present should be close to the updated metric 0) now efficiency of VAQ2 can be increased from 3% to 15% of bitrate depending of codec setup and filters.

PS
By the way, BugMaster (MasterNobody) already announce new variant of metric 4, I wait it appearance for the tests in vfw.
Probably in some time I can give a reference on cli version with all this metrics together from komisar666, BM will be ready with new builds not earlier tomorrow.

[nicko]

All who interested can find all versions of metrics from BugMaster in komisar666 builds:

x264 CLI 901 (58d7d06) fprofiled
http://komisar.gin.by/

Generic (http://komisar.gin.by/x264.901kVAQ2mod.PsyRDO.generic.pf.58d7d06.exe)
Athlon64-sse3 (http://komisar.gin.by/x264.901kVAQ2mod.PsyRDO.athlon64-sse3.athlon64-sse3.pf.58d7d06.exe)
AMDfam10 (http://komisar.gin.by/x264.901kVAQ2mod.PsyRDO.i686.amdfam10.pf.58d7d06.exe)
Core2 (http://komisar.gin.by/x264.901kVAQ2mod.PsyRDO.i686.core2.pf.58d7d06.exe)
MINGW32_NT-5.1 1.0.11(0.46/3/2) 2007-12-05 00:35 i686 Msys
gcc: gcc version 4.4.0 20080626 (experimental) (GCC)
yasm: 0.7.1.2093
avis input: yes; mp4 output: yes; pthread: yesUsed patches:
k.11.x264.progress.indication.01.diff (http://komisar.gin.by/x.patch/last.used/k.11.x264.progress.indication.01.diff)
999.x264_cosmetic_stdout.diff (http://komisar.gin.by/x.patch/last.used/999.x264_cosmetic_stdout.diff)
x264_frames_memoryleak.r870.diff (http://komisar.gin.by/x.patch/last.used/x264_frames_memoryleak.r870.diff)
x264_32x32samples_crash.r870.diff (http://komisar.gin.by/x.patch/last.used/x264_32x32samples_crash.r870.diff)
k.20.x264_fix_stats_file_work.r877.diff (http://komisar.gin.by/x.patch/last.used/k.20.x264_fix_stats_file_work.r877.diff)
x264_multithreading_Nth_pass_ratecontrol.r870.diff (http://komisar.gin.by/x.patch/last.used/x264_multithreading_Nth_pass_ratecontrol.r870.diff)
bm_x264_thread_pool.r870.diff (http://komisar.gin.by/x.patch/last.used/bm_x264_thread_pool.r870.diff)
k.22.PsyRDO.0.22.fixed.r889.diff (http://komisar.gin.by/x.patch/last.used/k.22.PsyRDO.0.22.fixed.r889.diff) (tuned by BugMaster/MasterNobody) MasterNobody post (http://forum.doom9.org/showthread.php?p=1151782#post1151782)
k.25.x264_hrd_pulldown.04_interlace.diff (http://komisar.gin.by/x.patch/last.used/k.25.x264_hrd_pulldown.04_interlace.diff)
k.24.qpfile_relax.diff (http://komisar.gin.by/x.patch/last.used/k.24.qpfile_relax.diff)
k.27.x264_vaq2mod.05.r892_and_old_4.diff (http://komisar.gin.by/x.patch/last.used/k.27.x264_vaq2mod.05.r892_and_old_4.diff) (VAQ2mod by BugMaster/MasterNobody)
--aq-metric 0: Slightly differ 4-metric from BugMaster. Current in GIT
--aq-metric 1: Partial overlapped block variance.
--aq-metric 2: Partial overlapped gaussian variance.
--aq-metric 3: Full overlapped gaussian variance (slowest).
--aq-metric 4: New whole-macroblock variance (fast). Original last metric from BugMaster (default for this build)
--aq-metric 5: Old whole-macroblock variance (fast). Original old metric from BugMasterDefault VAQ2mod settings:
--aq-mode 3 --aq-metric 4 --aq-strength 1.0
--aq-sensitivity 10.0 if manually selected aq-mode less than 3

[nicko]

Metric 5 was updated in all patches and builds ~half hour ago (some problem was detected).
http://komisar.gin.by/

[Razorholt]

Thanks nicko! :)

[nicko]

Thanks nicko! :)
Welcome!

It will be interesting to know your comparison tests for efficiency of these metrics (the most interesting are 0, 3, 4, 5).

[CruNcher]

--aq-metric 0 CRF = 24.7 SSIM = 0.9761215 PSNR= 42.481 BR= 1837.47
--aq-metric 1 CRF = 23.68 SSIM = 0.9762452 PSNR= 42.440 BR= 1836.49
--aq-metric 2 CRF = 23.67 SSIM = 0.9762865 PSNR= 42.463 BR= 1837.52
--aq-metric 3 CRF = 23.67 SSIM = 0.9762837 PSNR= 42.464 BR= 1837.13
--aq-metric 4 CRF = 23.47 SSIM = 0.9763673 PSNR= 42.482 BR= 1837.84
--aq-metric 5 = same result as 4 hmm
--current git build = 24.63 SSIM = 0.9761564 PSNR= 42.508 BR= 1835.71


compared to the current the difference is not that big Visualy it seems, tough i realized a rather big speedup +1,x fps (4,5) for the better SSIM wich is nice :)
it gives lower bitrate and better SSIM but a slightly lower Global PSNR but the Speedup is interesting i keep it for now :)

[nicko]

(4,5) for the better SSIM wich is nice :)
it gives lower bitrate and better SSIM but a slightly lower Global PSNR but the Speedup is interesting i keep it for now :)
Yes, better SSIM for several reason is more preferable than PSNR, it is my opinion.
As well speedup is interesting.

So, it means metric 4 or 5.

[Underground78]

Are you really sure that SSIM is reliable when dealing with an AQ ? Is a better SSIM always a proof of an improvement of the AQ ?

[CruNcher]

I like to refer it like this SSIM = Stability, PSNR = Detail Preservation and for Low Bitrate it's problematic (actually Physical impossible to preserve both) so you have to balance it right for the given scenario you are facing, for High Bitrate Stability is most of the times no issue and then Detail Preservation comes first :)

Tough my expereince told me starting with a PSNR lower then 40 the picture in motion slowly becomes unstable and the picture will most probably fall apart tough H.264 lifted this a little and can even keep a nice stable image @ an PSNR under 40 :)

The results in the other post are from a 720p @ 1.6x Realtime Live Transcode :)

And one tool wich rescues in extreme stability problem scenarios is the inloop deblocker it becomes esential @ very low bitrates, but the inloop deblocking as it currently is is not adaptable enough it needs to better adapt to the bitrate currently you have to manualy compensate in my eyes in different bitrate scenarios or you get super blurry response where it could have been avoided.

[LoRd_MuldeR]

Are you really sure that SSIM is reliable when dealing with an AQ ? Is a better SSIM always a proof of an improvement of the AQ ?

According to Dark Shikari metrics like PSNR and SSIM are useless to develop psychovisual extensions like VAQ and Psy RDO.

Nevertheless I think if the video actually looks better or equal (at same bitrate) while SSIM has improved, this cannot be wrong ;)

[nicko]

According to Dark Shikari metrics like PSNR and SSIM are useless to develop psychovisual extensions like VAQ and Psy RDO.

Nevertheless I think if the video actually looks better or equal (at same bitrate) while SSIM has improved, this cannot be wrong ;)
+1
Moreover a lot of depends from codec setup, small SSIM improving in standard setup can give an essential gain in the other case.
For example:
It is not visible from tests , but 4 and 5 metrics hardly reduce bitrate that in CRF-mode results to shift to small crf-values and finally noticeable increase a common quality in CRF. ;)

[nicko]

--aq-metric 0 = 24.7 SSIM = 0.9761215 PSNR= 42.481 BR= 1837.47 ....
--aq-metric 3 = 23.67 SSIM = 0.9762837 PSNR= 42.464 BR= 1837.13
--aq-metric 4 = 23.47 SSIM = 0.9763673 PSNR= 42.482 BR= 1837.84
--aq-metric 5 = same result as 4 hmm
--current git build = 24.63 SSIM = 0.9761564 PSNR= 42.508 BR= 1835.71


By the way, in my tests metric 3 about 20-30% slower than 0 and 4, please look ones more - there is no mistake here in FPS for aq-metric 3?

Second, metric 4 and 5 is equal in you tests, if do you use this build after update of metric 5?

[CruNcher]

nicko that is not FPS that is CRF adapted to get the same bitrate result (sorry i should have marked it better my fault corrected it) :)

and yes 3 is alot slower and since i could see no real visual difference i skip it (the cpu cycles spend currently seem wasted compared to the visual difference for now) this is the way im allways balanceing things out :) and that's also why i decided personaly to replace current git for my encodings with --aq-metric 4, because of the SSIM Gain and better speed (2 factors wich speak for it).

And yes i used komisars update (based on 895) that you posted here for the test that were Metric 5 was updated and Metric wise there is no difference in my test between 4,5 Visualy it's a subtitle difference per frame.

Komisar 901


--aq-metric 0 CRF = 22.7 SSIM = 0.9783996 PSNR = 42.897 BR = 1859.52 FPS = 32.23
--aq-metric 1 CRF = 21.68 SSIM = 0.9785048 PSNR = 42.850 BR = 1858.93 FPS = 31.81
--aq-metric 2 CRF = 21.68 SSIM = 0.9785165 PSNR = 42.869 BR = 1859.50 FPS = 22.33
--aq-metric 3 CRF = 21.68 SSIM = 0.9785271 PSNR = 42.871 BR = 1858.56 FPS = 9.01
--aq-metric 4 CRF = 21.47 SSIM = 0.9786268 PSNR = 42.893 BR = 1859.73 FPS = 32.27
--aq-metric 5 CRF = 21.52 SSIM = 0.9786164 PSNR = 42.899 BR = 1858.00 FPS = 32.35
--git (901) CRF = 22.61 SSIM = 0.9784656 PSNR = 42.934 BR = 1860.07 FPS = 31.26

[nicko]

CruNcher

OK

Many thanks for answers and table!

Now it is good illustration for my words about shift of CRF to a smaller values for metric 4 (5) in comparison with GIT and 0. :)

[Sharktooth]

lower CRF at the same bitrate? something's wrong ....

[Dark Shikari]

lower CRF at the same bitrate? something's wrong ....Arbitrarily adjusting "sensitivity" is equivalent to adjusting CRF. That's why I removed the option...

[nicko]

For some rason lower CRF is better than higher "sensitivity" with the same bitrate.

Quality in CRF-mode is not equivalent only "sensitivity".

Actually the key point is - maximum quality/bitrate is shifted to the smaller CRF, which is better than opposite case.

[Sharktooth]

exactly. so if a metric changes the CRF then something's just plain wrong...
you cant lower or change the CRF and mantain the same bitrate... it's just a nonsense.

[nicko]

exactly. so if a metric changes the CRF then something's just plain wrong...
you cant lower or change the CRF and mantain the same bitrate... it's just a nonsense.

Actually not. But probably yes, if its belong a common idea of CRF -mode.

CRF is not pure spatial linear coding parameter.

For example at higher CRF a part of temporal compression is increased (agrees with psychovisual coding script), which is can not be compensated by only one spatial parameter.
So it is preferable to decrease CRF.

By other words:
The same rip made with metric 4(5) & CRF~24.5 looks much better than with GIT (metric 0) & СRF~26 with equal bitrate.

I think somebody should use this for further improvement of codec quality/bitrate.

[Dark Shikari]

Really not. Or its belong a common idea of CRF -mode.
Actually CRF is not pure spatial linear coding parameter.
For example at higher CRF a part of temporal compression is increased (agrees with psychovisual coding script), which is can not be compensated by only one spatial parameter.

By other words:
The same rip made with metric 4(5) & CRF~24.5 looks much better than with GIT (metric 0) & СRF~26 with equal bitrate.

I think somebody should use this for further improvement of codec quolity/bitrate.Except that git now uses "metric 4" :rolleyes:

[nicko]

Except that git now uses "metric 4" :rolleyes:
Some "small" differences still existed. From Komisar666 words:

GIT: *satd += h->pixf.satd[pix]( zero, 0, h->fenc->plane[i]+offset, stride ) - sad/2;
BM: *satd += h->pixf.satd[pix]( zero, 0, h->fenc->plane[i]+offset, stride );

delta CRF (GIT, metric4) ~1.2... ;)

As I told, imho, it is not obviously equivalent to compensate bitrate by CRF+metric or sensitivity.

Yes, it would be the best solution to find this hole in codec direct. :)

I hope Sharktooth is right and somebody can solve this task finaly without metrics.

[CruNcher]

@nicko
Could you ask Komisar666 if he could additionaly compile a libx264.dll of his build and make it available @ the side of the cli encoder for Avidemux usage, that would be really great :)

Update 906 (CRF)


--aq-metric 4 CRF = 20.34 SSIM = 0.9812044 PSNR = 43.567 BR = 2187.61 FPS = 34.57
--git (906) CRF = 21.47 SSIM = 0.9810663 PSNR = 43.610 BR = 2189.67 FPS = 33.61


(Bitrate)


--aq-metric 4 BRT = 1860 BRH = 1816.13 FCRF = 20.88 SSIM = 0.9767143 PSNR = 42.354 FPS = 36.08
--git (906) BRT = 1860 BRH = 1829.05 FCRF = 22.01 SSIM = 0.9766777 PSNR = 42.410 FPS = 34.77


Visualy it makes really no difference (comparing the overal PSNR for git vs the overal SSIM for komissars build) tough the speedup is the most visible here i gonna try some very low bitrate stuff next to see where it visualy starts to make a difference (if @ all).

[nicko]

@nicko
Could you ask Komisar666 if he could additionaly compile a libx264.dll of his build and make it available @ the side of the cli encoder for Avidemux usage, that would be really great :)

CruNcher
OK
I'll transmit your request to komisar666

By the way
906 Cli is ready
http://komisar.gin.by/


Update 906 (CRF)


--aq-metric 4 CRF = 20.34 SSIM = 0.9812044 PSNR = 43.567 BR = 2187.61 FPS = 34.57
--git (906) CRF = 21.47 SSIM = 0.9810663 PSNR = 43.610 BR = 2189.67 FPS = 33.61


(Bitrate)


--aq-metric 4 BRT = 1860 BRH = 1816.13 FCRF = 20.88 SSIM = 0.9767143 PSNR = 42.354 FPS = 36.08
--git (906) BRT = 1860 BRH = 1829.05 FCRF = 22.01 SSIM = 0.9766777 PSNR = 42.410 FPS = 34.77


Visualy it makes really no difference (comparing the overal PSNR for git vs the overal SSIM for komissars build) tough the speedup is the most visible here i gonna try some very low bitrate stuff next to see where it visualy starts to make a difference (if @ all).

Thanks for tests!

Yes, better to look it at ~250-500 kbps (CRF~24-26), than result is more visible. :)

[CruNcher]

At low bitrate it really shows it's performance visualy it's still hard to track the difference i would say you have less b-frame distortion problems (better stability in motion) in some scenes then with the git version


--aq-metric 4 CRF = 31.21 SSIM = 0.9447644 PSNR = 37.496 BR = 524.25 FPS = 44.71
--git (906) CRF = 32.44 SSIM = 0.9441511 PSNR = 37.505 BR = 524.50 FPS = 43.23

[nicko]

At low bitrate it really shows it's performance visualy it's still hard to track the difference i would say you have less b-frame distortion problems (better stability in motion) in some scenes then with the git version


--aq-metric 4 CRF = 31.21 SSIM = 0.9447644 PSNR = 37.496 BR = 524.25 FPS = 44.71
--git (906) CRF = 32.44 SSIM = 0.9441511 PSNR = 37.505 BR = 524.50 FPS = 43.23

OK
Thanks!
delta CRF (GIT, metric4) ~1.23

Actually for such tests is important codec setup,
I have some very extremal setup-version with --aq-strength~1.6-2 (Dark Shikari thanks for VAQ2, now together with metric 4 this magic is possible without artefacts for very high aq-strength -thanks BM) to made a relatively good quality rips with 240-600kbps for 704x528, which is very sensitive for such changes...

[Razorholt]

@nicko: how about VAQ2+PsyRDO0.5 ? :D

Thanks,
- Dan

[nicko]

@nicko: how about VAQ2+PsyRDO0.5 ? :D

Thanks,
- Dan
It is question to komisar666, I hope he will be taken by it.

Vfw-VAQ2+PsyRDO-0.5 version should be complited by BugMaster

[nicko]

@nicko
Could you ask Komisar666 if he could additionaly compile a libx264.dll of his build and make it available @ the side of the cli encoder for Avidemux usage, that would be really great :)



Unfortunately, it seems practically is impossible, after long discussions and attempts several experts were stated that such operation by correct way is possible only for GIT, therefore developers Avidemux if they interested to work with new advanced codecs version are obliged to adapt new x264 builds for Avidemux themselves or to adapt Avidemux for new x264 builds. :(


Now good news.

BugMaster uploaded a new stable 912vfw builds with new variant of metric 4 (by definition, a bit different from the versions in komisar666 build), Psy RDO-0.5 and many other features ....

x264vfw_13_912bm_VAQ2mod_PsyRDO_14208.exe

and standard build
x264vfw_13_912bm_14208.exe

http://sourceforge.net/project/showfiles.php?group_id=213809

[nicko]

All who wants to take part in testing of a full set of the metrics (0-12, all together 13) from BugMaster can take complete-metric builds based on b912 here:

VFW: http://stashbox.org/159397/x264vfw_13_912bm_VAQ2test_PsyRDO_14208_more.exe
CLI: http://stashbox.org/159398/x264_test_more.exe


Parameters by definition
- aq-mode=2 "aq-sensitivity can be adjusted by hand"
- aq-metric=0 "it is a GIT (or bm_M6_4ver0c)"
- aq-sensitivity=logf(5000)
- qcomp=1
- psy-rd=0 "for tests better to swich off"

To swich off VAQ for comparison, one can use aq-mode=0.

PS
Be care, --help in CLI is not updated!

[nicko]

BM fixed important bug in lossless CRF (and others modes, 2pass...) broked in r901.

r913vfw

x264vfw_13_913bm_VAQ2mod_PsyRDO_14259.exe
x264vfw_13_913bm_14259.exe

http://sourceforge.net/project/showfiles.php?group_id=213809

PS
For metric-test-bulds not important (axcept lossless mode, CRF=0,...).

[DarkZell666]

BM fixed important bug in lossless CRF.
b913vfw

x264vfw_13_913bm_VAQ2mod_PsyRDO_14259.exe
x264vfw_13_913bm_14259.exe

http://sourceforge.net/project/showfiles.php?group_id=213809

PS
For metric-test-bulds not important (axcept lossless CRF).

Is it me .... or aren't "lossless" and "CRF" actually supposed to be mutually exclusive ? ...

[Dark Shikari]

Is it me .... or aren't "lossless" and "CRF" actually supposed to be mutually exclusive ? ...CRF==0 is the same as QP==0 is the same as lossless.

[CruNcher]

@nicko
is it correct that in the new AQ test build the CRF range changed dramaticly (less precise then before) so most of the times float values like xx.xx have no effect anymore compared to xx.x ?.

[nicko]

@nicko
is it correct that in the new AQ test build the CRF range changed dramaticly (less precise then before) so most of the times float values like xx.xx have no effect anymore compared to xx.x ?.

Now I can not tell you - I can begin the tests only today evening.

But earlier at me such happened only when I worked with old computers (Intel-P4, ....).

Do you use now the same computer as before?

[elguaxo]

BM fixed important bug in lossless CRF (and others modes, 2pass...) broked in r901.

What was the problem exactly? I have two lossless encodes that I did with r901 and I'm wondering if I should them again. Thanks!

[Dark Shikari]

What was the problem exactly? I have two lossless encodes that I did with r901 and I'm wondering if I should them again. Thanks!Image corruption in any i16x16 macroblock due to a slight coding error of mine.

[elguaxo]

Image corruption in any i16x16 macroblock due to a slight coding error of mine.

thanks for the quick answer! :)

[nicko]

What was the problem exactly? I have two lossless encodes that I did with r901 and I'm wondering if I should them again. Thanks!
The speech went about serious distortions of a picture.

[CruNcher]

@nicko



912 (revision before the AQ changes ) --aq-metric 4

--aq-mode 0 CRF = 23.33 SSIM = 0.9796536 PSNR = 43.497 BR = 1848.94 FPS = 32.15
--aq-mode 0 CRF = 23.36 SSIM = 0.9795736 PSNR = 43.476 BR = 1840.99 FPS = 32.50

--aq-mode 1 CRF = 22.66 SSIM = 0.9802948 PSNR = 43.269 BR = 1850.19 FPS = 30.35
--aq-mode 1 CRF = 22.7 SSIM = 0.9802133 PSNR = 43.248 BR = 1840.99 FPS = 30.19

--aq-mode 2 CRF = 23.35 SSIM = 0.9799445 PSNR = 43.110 BR = 1848.04 FPS = 30.72
--aq-mode 2 CRF = 23.38 SSIM = 0.9798735 PSNR = 43.092 BR = 1839.74 FPS = 30.73

--aq-mode 3 CRF = 21.86 SSIM = 0.9799475 PSNR = 43.097 BR = 1849.66 FPS = 30.25
--aq-mode 3 CRF = 21.9 SSIM = 0.9798579 PSNR = 43.074 BR = 1839.68 FPS = 30.26


912 (new AQ test) --aq-metric 4

--aq-mode 0 CRF = 25 SSIM = 0.9798004 PSNR = 43.672 BR = 1849.40 FPS = 31.70

--aq-mode 1 CRF = 25.46 SSIM = 0.9800692 PSNR = 43.388 BR = 1839.20 FPS = 29.94

--aq-mode 2 CRF = 23.5 SSIM = 0.9802944 PSNR = 43.319 BR = 1845.20 FPS = 30.48
--aq-mode 2 CRF = 23.53 SSIM = 0.9802486 PSNR = 43.306 BR = 1838.80 FPS = 30.24

--aq-mode 3 CRF = 25.55 SSIM = 0.9803369 PSNR = 43.341 BR = 1849.31 FPS = 29.87
--aq-mode 3 CRF = 25.6 SSIM = 0.9802577 PSNR = 43.319 BR = 1839.99 FPS = 29.83

[nicko]

@nicko



912 (revision before the AQ changes ) --aq-metric 4

--aq-mode 0 CRF = 23.33 SSIM = 0.9796536 PSNR = 43.497 BR = 1848.94 FPS = 32.15
--aq-mode 0 CRF = 23.36 SSIM = 0.9795736 PSNR = 43.476 BR = 1840.99 FPS = 32.50

--aq-mode 1 CRF = 22.66 SSIM = 0.9802948 PSNR = 43.269 BR = 1850.19 FPS = 30.35
--aq-mode 1 CRF = 22.7 SSIM = 0.9802133 PSNR = 43.248 BR = 1840.99 FPS = 30.19

--aq-mode 2 CRF = 23.35 SSIM = 0.9799445 PSNR = 43.110 BR = 1848.04 FPS = 30.72
--aq-mode 2 CRF = 23.38 SSIM = 0.9798735 PSNR = 43.092 BR = 1839.74 FPS = 30.73

--aq-mode 3 CRF = 21.86 SSIM = 0.9799475 PSNR = 43.097 BR = 1849.66 FPS = 30.25
--aq-mode 3 CRF = 21.9 SSIM = 0.9798579 PSNR = 43.074 BR = 1839.68 FPS = 30.26


912 (new AQ test) --aq-metric 4

--aq-mode 0 CRF = 25 SSIM = 0.9798004 PSNR = 43.672 BR = 1849.40 FPS = 31.70

--aq-mode 1 CRF = 25.46 SSIM = 0.9800692 PSNR = 43.388 BR = 1839.20 FPS = 29.94

--aq-mode 2 CRF = 23.5 SSIM = 0.9802944 PSNR = 43.319 BR = 1845.20 FPS = 30.48
--aq-mode 2 CRF = 23.53 SSIM = 0.9802486 PSNR = 43.306 BR = 1838.80 FPS = 30.24

--aq-mode 3 CRF = 25.55 SSIM = 0.9803369 PSNR = 43.341 BR = 1849.31 FPS = 29.87
--aq-mode 3 CRF = 25.6 SSIM = 0.9802577 PSNR = 43.319 BR = 1839.99 FPS = 29.83



Many thanks!

I did not get which version is it, can you give a references on this builds?

Imho, here valid comparison only in aq-mode 2, as for other definition parameters can be different vor this versions of codec.

And in 2-d version of metric 4 I see a good changes!

[nicko]

Now I finished my metrics tests.

I used 3 builds:
1. r889
2. r812-test, through numbers I take from this version (M0-M12)
3.r813

Bitrate was adjusted with the help of aq-sensitivity, imho, the most correct way which is not affects a temporal part of codec.


r889-metr4-(M7)-q25-sensitivity 8.3
x264vfw [info]: SSIM Mean Y:0.9542146
x264vfw [info]: PSNR Mean Y:35.724 U:41.165 V:41.565 Avg:36.911 Global:36.667 kb/s:585.59


r913-metr4-(M6)-q25-sensitivity 8.3024
x264vfw [info]: SSIM Mean Y:0.9541604
x264vfw [info]: PSNR Mean Y:35.692 U:41.165 V:41.540 Avg:36.882 Global:36.643 kb/s:585.97


r912test-metr6-(M6)-q25-sensitivity 8.3024
x264vfw [info]: SSIM Mean Y:0.9541604
x264vfw [info]: PSNR Mean Y:35.692 U:41.165 V:41.540 Avg:36.882 Global:36.643 kb/s:585.97


r912test-metr6-(M6)-q25-sensitivity8.3
x264vfw [info]: SSIM Mean Y:0.9541724
x264vfw [info]: PSNR Mean Y:35.576 U:40.820 V:41.312 Avg:36.740 Global:36.523 kb/s:582.30


r912test-metr0-(M0)-q25-sensitivity 8.295
x264vfw [info]: SSIM Mean Y:0.9541020
x264vfw [info]: PSNR Mean Y:35.706 U:41.169 V:41.523 Avg:36.893 Global:36.647 kb/s:609.71

r912test-metr4-(M4)-q25-sensitivity 8.295
x264vfw [info]: SSIM Mean Y:0.9540974
x264vfw [info]: PSNR Mean Y:35.705 U:41.186 V:41.555 Avg:36.895 Global:36.651 kb/s:609.12


r912test-metr3-(M3)-q25-sensitivity7.581
x264vfw [info]: SSIM Mean Y:0.9529578
x264vfw [info]: PSNR Mean Y:35.803 U:41.986 V:42.312 Avg:37.069 Global:36.716 kb/s:590.45

r912test-metr3-(M3)-q25-sensitivity7.564
x264vfw [info]: SSIM Mean Y:0.9524461
x264vfw [info]: PSNR Mean Y:35.692 U:41.870 V:42.182 Avg:36.957 Global:36.631 kb/s:581.62


r912test-metr3-(M3)-q25-sensitivity7.568
x264vfw [info]: SSIM Mean Y:0.9526719
x264vfw [info]: PSNR Mean Y:35.775 U:41.954 V:42.267 Avg:37.040 Global:36.690 kb/s:587.11


r912test-metr8-(M8-)q25-sensitivity8.294
x264vfw [info]: SSIM Mean Y:0.9541336
x264vfw [info]: PSNR Mean Y:35.692 U:41.182 V:41.578 Avg:36.886 Global:36.643 kb/s:600.32

r912test-metr12-(M12)-q25-sensitivity7.568
x264vfw [info]: SSIM Mean Y:0.9526719
x264vfw [info]: PSNR Mean Y:35.775 U:41.954 V:42.267 Avg:37.040 Global:36.690 kb/s:587.11


r912test-metr11-(M11)-q25-sensitivity7.568
x264vfw [info]: SSIM Mean Y:0.9527516
x264vfw [info]: PSNR Mean Y:35.759 U:41.938 V:42.261 Avg:37.024 Global:36.678 kb/s:589.43


r912test-metr10-(M10)-q25-sensitivity7.6
x264vfw [info]: SSIM Mean Y:0.9511864
x264vfw [info]: PSNR Mean Y:35.647 U:41.985 V:42.305 Avg:36.930 Global:36.562 kb/s:585.51

r912test-metr5-(M5)-q25-sensitivity8.295
x264vfw [info]: SSIM Mean Y:0.9540974
x264vfw [info]: PSNR Mean Y:35.705 U:41.186 V:41.555 Avg:36.895 Global:36.651 kb/s:609.12


r912test-metr7-(M7)-q25-sensitivity8.3
x264vfw [info]: SSIM Mean Y:0.9541724
x264vfw [info]: PSNR Mean Y:35.576 U:40.820 V:41.312 Avg:36.740 Global:36.523 kb/s:582.30

r912test-metr7-(M7)-q25-sensitivity8.3024
x264vfw [info]: SSIM Mean Y:0.9541604
x264vfw [info]: PSNR Mean Y:35.692 U:41.165 V:41.540 Avg:36.882 Global:36.643 kb/s:585.97

r912test-metr9(M9)-q25-sensitivity8.297
x264vfw [info]: SSIM Mean Y:0.9541933
x264vfw [info]: PSNR Mean Y:35.728 U:41.164 V:41.548 Avg:36.914 Global:36.667 kb/s:601.92

Now only winners:

r889-metr4-(M7)-q25-sensitivity 8.3
x264vfw [info]: SSIM Mean Y:0,9542146
x264vfw [info]: PSNR Mean Y:35.724 U:41.165 V:41.565 Avg:36.911 Global:36.667 kb/s:585,59


r913-metr4-(M6)-q25-sensitivity 8.3024
x264vfw [info]: SSIM Mean Y:0.9541604
x264vfw [info]: PSNR Mean Y:35.692 U:41.165 V:41.540 Avg:36.882 Global:36.643 kb/s:585.97

r912test-metr6-(M6)-q25-sensitivity8.3.avi
x264vfw [info]: SSIM Mean Y:0.9541724
x264vfw [info]: PSNR Mean Y:35.576 U:40.820 V:41.312 Avg:36.740 Global:36.523 kb/s:582.30


r912test-metr6-(M6)-q25-sensitivity 8.3024.avi
x264vfw [info]: SSIM Mean Y:0.9541604
x264vfw [info]: PSNR Mean Y:35.692 U:41.165 V:41.540 Avg:36.882 Global:36.643 kb/s:585.97


r912test-metr7-(M7)-q25-sensitivity8.3024.avi
x264vfw [info]: SSIM Mean Y:0.9541604
x264vfw [info]: PSNR Mean Y:35.692 U:41.165 V:41.540 Avg:36.882 Global:36.643 kb/s:585.97

r912test-metr7-(M7)-q25-sensitivity8.3.avi
x264vfw [info]: SSIM Mean Y:0.9541724
x264vfw [info]: PSNR Mean Y:35.576 U:40.820 V:41.312 Avg:36.740 Global:36.523 kb/s:582.30


M6 и М7 in r912-test and r913 are equal (as predicted by BM for aq-mode 2)

For some reason M7 from r889 a tiny bit ahead than M6 and М7 in new revision, but I think it is only changes inside codec itself.

So for my test winner is metric by definiton 4 (or M6 from r912test ) from r913.

[komisar]

Some tests with various "aq-metric" and visual comparsion:
http://komisar.gin.by/mtest/

P.S. In my last x264 builds present only GIT, 4ver0 and 4ver1 metrics...

[Sharktooth]

using PSNR and SSIM for comparing AQ metrics is useless. at that point you would better use PSNR or SSSIM in place of the AQ metric...
AQ is all about visuals... comparing using metrics you're destroying the AQ original intent.

[komisar]

I understand... But you may see "visual comparsion"...

[Warpman]

I understand... But you may see "visual comparsion"...

you hide the sceenshots very well ;)

[Sharktooth]

i mean... dont rely on PSNR or SSIM... higher values do not mean better IQ.
you need to look at comparative pictures or clips.

[komisar]

Pay attention to "avgQ" column in tables and "CMPLX"
avgQ -- average (I+P+B) quant for all frames;
CMPLX -- average bits for one macroblock encoding;
I upload all testing material here:
http://komisar.gin.by/test/

[Sharktooth]

that doesnt express visual quality.

[komisar]

But you can see difference (or make you own tests)... Quality low because CRF=26 used...
You may compare frame redistribute...
(sorry, i not have sufficient HDD space for all test result)

[nm]

that doesnt express visual quality.
He does have easily comparable screenshots there. Click the links at the top of the page (for example: http://komisar.gin.by/mtest/03_2pass.html).
And the full clips are also available in the test directory.

[Sharktooth]

they're well hidden... :)

[komisar]

:-) Sorry, I add red description above links to visual comparsion...

[Sharktooth]

i would change it in "right below there are the links for a visual comparison" though.

[komisar]

Ok. Changed...

[Sharktooth]

uhm... "...there are links..." maybe it's better... english is not my native language
btw, i would also add a blind test visual comparison instead of choosing places by metrics.

[komisar]

You have taunted me? English is not my native language. Who wants, he will find what it needs...

[Sharktooth]

no, i probably made a mistake in the phrase i suggested you, so actually i taunted myself...

[Quark.Fusion]

From 2-pass screenshots I vote for this:
http://komisar.gin.by/mtest/03_2pass/mtst_2pass_3_11_0000.png
But it may be borrowed bits from other frames

And for same method from CRF-BR:
http://komisar.gin.by/mtest/05_crf1/mtst_crf1_3_11_0000.png
CRF-BR is also better for this frame

[komisar]

Ok. It is important not language expression, and the result.

[komisar]

From 2-pass screenshots I vote for this:
But it may be borrowed bits from other frames
And for same method from CRF-BR:
CRF-BR is also better for this frame
Did you forget to specify metric used in the screenshots. (This is 11, or 4ver1)

aq-mode 3 by BugMaster is 3: Hybrid mode of moving bitsAlso metrics, for which the "Final AQ sensitivity" smaller (AQS column in my tables), better save bitrate.

[CruNcher]

From 2-pass screenshots I vote for this:
http://komisar.gin.by/mtest/03_2pass/mtst_2pass_3_11_0000.png
But it may be borrowed bits from other frames

And for same method from CRF-BR:
http://komisar.gin.by/mtest/05_crf1/mtst_crf1_3_11_0000.png
CRF-BR is also better for this frame

yeah and that's the problem how does the difference look in Motion, and then i think for most mini differences there it wouldn't be much different Visualy but then you can go look @ the Speed/Bitrate and then it gets quite clear wich seem to be very efficient :) my tendency here also goes to 4ver1

[nicko]

Sory for delay but from this test http://komisar.gin.by/mtest/03_2pass.html

4ver0 looks a litle bit better (see a soft details on a dark background) even than 4ver1.

[komisar]

New tests for new version of VAQ modification by BugMaster named AutoVAQ.
Main tests place (http://komisar.gin.by/avaq/index.html) (with visual comparsion)
Builds named kAVAQ from main page (http://komisar.gin.by/)

[Dark Shikari]

New tests for new version of VAQ modification by BugMaster named AutoVAQ.
Main tests place (http://komisar.gin.by/avaq/index.html) (with visual comparsion)
Builds named kAVAQ from main page (http://komisar.gin.by/)Use a different thread; don't bump one that's half a year old.