AutoVAQ patch testing

[MasterNobody]

I think it is the time for testing my experimental AutoVAQ patch (http://stashbox.org/502291/x264_AutoVAQ.02.diff) (updated 03 version (http://stashbox.org/549826/x264_AutoVAQ.03.diff) which doesn't overwrite standard VAQ and add "--aq-mode 2" option for activating AutoVAQ) in wider audience than users of #x264dev IRC-channel and small Russian-speaking group of people. The main purpose of this patch was to make algorithm automaticaly choose close to optimal strength of AQ (on per frame base) and by this increase quality of encoding (without need of manually finding optimal strength for every source).
Patch does not add or remove any x264 options but replace the current offical VAQ implementation. The algorithm is tweaked to "--aq-strength 1.0" (which is default) and changing of this parameter is not recommended.
For testing you may use:
- my reference x264 CLI build (http://stashbox.org/515099/x264_AutoVAQ.exe) based on x264 revision 1148 (non fprofiled, without MP4 support, no other patches)
- Komisar's kAVAQ builds (http://komisar.gin.by/)
- LoRd_MuldeR's libx264 binaries for Avidemux (http://forum.doom9.org/showthread.php?p=1284949#post1284949)
- or build x264 yourself with AutoVAQ patch (http://stashbox.org/502291/x264_AutoVAQ.02.diff)
For comparison you may need clean x264 CLI build (http://x264.nl/).

Here is comparison of current offical VAQ (StdVAQ) and my AutoVAQ builds on two rather different samples (for which optimal strength of StdVAQ differ considerably):

Parkrun encodes (http://www.mediafire.com/file/vdeevfhywjw/parkrun.zip) of Parkrun source (ftp://ftp.ldv.e-technik.tu-muenchen.de/pub/test_sequences/720p/720p50_parkrun_ter.yuv) with base options:
--fps 25 --threads 3 --8x8dct --b-adapt 2 --bframes 4 --b-pyramid --weightb --ref 3 --mixed-refs --me umh --subme 9 --trellis 2 --no-fast-pskip
without Psy options (--psy-rd 0.0:0.0):
StdVAQ --crf 28.00 --aq-strength 1.0 SSIM Y: 0.8383909 APSNR: 28.364 OPSNR: 28.001 kb/s: 1568.94
StdVAQ --crf 26.15 --aq-strength 1.5 SSIM Y: 0.8486719 APSNR: 28.151 OPSNR: 27.764 kb/s: 1568.91
StdVAQ --crf 24.65 --aq-strength 2.0 SSIM Y: 0.8514804 APSNR: 27.749 OPSNR: 27.292 kb/s: 1571.41
AutoVAQ --crf 30.23 --aq-strength 1.0 SSIM Y: 0.8586000 APSNR: 28.077 OPSNR: 27.724 kb/s: 1567.00
with Psy options (--psy-rd 1.0:0.3):
StdVAQ --crf 29.33 --aq-strength 1.0 SSIM Y: 0.8316043 APSNR: 27.694 OPSNR: 27.318 kb/s: 1570.51
StdVAQ --crf 27.56 --aq-strength 1.5 SSIM Y: 0.8395926 APSNR: 27.439 OPSNR: 27.039 kb/s: 1571.78
StdVAQ --crf 26.18 --aq-strength 2.0 SSIM Y: 0.8397329 APSNR: 26.980 OPSNR: 26.509 kb/s: 1573.75
AutoVAQ --crf 31.58 --aq-strength 1.0 SSIM Y: 0.8500254 APSNR: 27.386 OPSNR: 27.021 kb/s: 1568.49

Azumanga encodes (http://www.mediafire.com/file/drya23yrz0y/azumanga.zip) of Azumanga source (http://mirror05.x264.nl/Dark/LosslessAzumanga.mkv) with base options:
--frames 1156 --fps 25 --threads 3 --8x8dct --b-adapt 2 --bframes 4 --b-pyramid --weightb --ref 3 --mixed-refs --me umh --subme 9 --trellis 2 --no-fast-pskip
without Psy options (--psy-rd 0.0:0.0):
StdVAQ --crf 29.55 --aq-strength 0.5 SSIM Y: 0.9921343 APSNR: 41.893 OPSNR: 41.173 kb/s: 297.54
StdVAQ --crf 28.00 --aq-strength 1.0 SSIM Y: 0.9922015 APSNR: 41.575 OPSNR: 40.809 kb/s: 297.78
StdVAQ --crf 26.63 --aq-strength 1.5 SSIM Y: 0.9919121 APSNR: 41.084 OPSNR: 40.249 kb/s: 297.91
StdVAQ --crf 25.50 --aq-strength 2.0 SSIM Y: 0.9911979 APSNR: 40.387 OPSNR: 39.479 kb/s: 298.04
AutoVAQ --crf 26.78 --aq-strength 1.0 SSIM Y: 0.9921364 APSNR: 41.837 OPSNR: 40.989 kb/s: 297.46
with Psy options (--psy-rd 1.0:0.3):
StdVAQ --crf 31.13 --aq-strength 0.5 SSIM Y: 0.9903588 APSNR: 41.438 OPSNR: 40.598 kb/s: 297.76
StdVAQ --crf 29.67 --aq-strength 1.0 SSIM Y: 0.9901783 APSNR: 40.989 OPSNR: 40.099 kb/s: 298.11
StdVAQ --crf 28.55 --aq-strength 1.5 SSIM Y: 0.9893354 APSNR: 40.279 OPSNR: 39.318 kb/s: 298.30
StdVAQ --crf 27.60 --aq-strength 2.0 SSIM Y: 0.9880089 APSNR: 39.444 OPSNR: 38.410 kb/s: 298.44
AutoVAQ --crf 28.35 --aq-strength 1.0 SSIM Y: 0.9903360 APSNR: 41.409 OPSNR: 40.418 kb/s: 297.76

I wouldn't make any conclusions from these tests. Make your own comparison (on other sources) and write yours results and conclusions.

[LoRd_MuldeR]

Hi. I noticed that with the AutoVAQ patch I get significant smaller files in CRF mode. Like ~15% smaller at CRF=22.

Of course I can lower the CRF value by one or two in order to compensate. But is this intended?

[MasterNobody]

Hi. I noticed that with the AutoVAQ patch I get significant smaller files in CRF mode. Like ~15% with CRF=22.

Of course I can lower the CRF value by one or two in order to compensate. But is this intended?
Yes, this is intended that it changes CRF/size ratio and you need probably find new CRF which give good quality (and it can not only decrease size but also increase it on other sources). Look at my comparison. For Parkrun sample it increases size on the same CRF and for Azumanga sample it decreases size on the same CRF.

[Dark Shikari]

When I eventually commit this, it will (for the fourth time) rebalance CRF.

[LoRd_MuldeR]

Okay. Thanks for the info.

(BTW: May it be possible to apply this patch in a way that doesn't need GCC 4.x and the "force_align_arg_pointer" attribute to prevent crash? Tried using "x264_stack_align()", but it only accepts one param)

[LoRd_MuldeR]

http://img12.imageshack.us/img12/3037/autovaqdefault.png

http://img14.imageshack.us/img14/6080/autovaqenabled.png

Encoding settings: cabac=1 / ref=8 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=9 / psy_rd=1.0:0.2 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-3 / threads=6 / nr=0 / decimate=1 / mbaff=0 / bframes=5 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / keyint=250 / keyint_min=25 / scenecut=40 / rc=2pass / bitrate=1500 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00

I find the Non-AutoVAQ version more pleasing with this source :o

[Dark Shikari]

Single-frame comparisons are completely useless for this patch for the following reasons:

1. The patch inherently reverts AQ's effect on redistribution of bits. This may reduce the quality of some frames and increase the quality of others.

2. This patch changes AQ on a per-frame basis. In theory, some frames could get worse.

[LoRd_MuldeR]

Somehow I need to compare and it's really hard to compare two encodes in full playback speed. So I step through the interleaved video frame by frame. How do you do it?

Also I can find many frames like that in my encode where the Non-AutoVAQ version looks more pleasing. But I hardly see any frames that actually look better with AutoVAQ.

[Dark Shikari]

Somehow I need to compare and it's really hard to compare two encodes in full playback speed. So I step through the interleaved video frame by frame. How do you do it?

Also I can find many frames like that in my encode where the Non-AutoVAQ version looks more pleasing. But I hardly see any frames that actually look better with AutoVAQ.Pick a whole bunch of different frames.

Also, adjust the AQ strength. If it is overall worse, try adjusting the AQ strength until you can make it look better. If you can't, then it's worse, if you can, then its default is bad.

[Dark Shikari]

Specifically, there are three things about this patch that have to be tested separately:

1. Is its default AQ value good?

2. Is the ratio between AQ values in different frames good? That is, is the "auto" part of AutoVAQ good?

3. Is the distribution of quantizers in a single frame, ignoring the AQ strength of that frame, good? This patch is not really VAQ, as it uses a different metric. I'd call it more like "Hadamard Variance Adaptive Quantization", or HVAQ. Or VHAQ.

[MasterNobody]

Also I can find many frames like that in my encode where the Non-AutoVAQ version looks more pleasing. But I hardly see any frames that actually look better with AutoVAQ.
I would recommend to compare CRF-encodes with close bitrates (because of problem with few first frames in 2-pass encoding and high quant for first I-frame) or at least at long samples (with more than three I-frames). Also it would be good if you provide the source sample if you think that at it AutoVAQ gives considerably worse results than StdVAQ. How long is this sample?

[LoRd_MuldeR]

Pick a whole bunch of different frames.

Well, I scanned through the entire video and I easily spotted worse looking frames, but no better looking ones.

Also, adjust the AQ strength. If it is overall worse, try adjusting the AQ strength until you can make it look better. If you can't, then it's worse, if you can, then its default is bad.

Will try to do some more tests with different AQ strengths...

[LoRd_MuldeR]

I would recommend to compare CRF-encodes with close bitrates (because of problem with few first frames in 2-pass encoding and high quant for first I-frame) or at least at long samples (with more than three I-frames). Also it would be good if you provide the source sample if you think that at it AutoVAQ gives considerably worse results than StdVAQ. How long is this sample?

From all that I learned using CRF for comparison is a bad idea. Especially because the AutoVAQ version would be ~15% smaller in size. Using two 2-Pass encodes of the same (average) bitrate is highly recommended. Also my test sequence was a 5000 frame clip (taken from an even longer source). Long enough I guess. And the screenshot above was not taken from the very first part of the sequence.

[MasterNobody]

From all that I learned using CRF for comparison is a bad idea.I am not talking about comparison on the same CRF but on the CRFs that gives close bitrate.
Also my test sequence was a 5000 frame clip (taken from an even longer source). Long enough I guess.Yes, this is long enough.

[kemuri-_9]

hmm...

i would gander that if the new algo permanently replaces the current algo, there's probably gonna be (yet another) rush of complaints,
with some of them being 'I want the old version back because of xxxx!'

I also didn't notice anything in the patch code to prevent the aq-strength from being altered,
this would be currently due to the testing state of the patch to allow modifications for further testing,
but it has already been stated to be optimized for aq-strength=1.0,
so will the final version prevent such changes or at least warn when the value is changed?

I would say the ride would be less bumpy if it was instituted as a new aq-mode rather than completely replacing the current algorithm...
even if the majority consensus says the new version is better, chances are there will be some that claim the old version is better and would like to keep using it.
(On this point, what is the consensus as of yet?)


more on the testing sides of things when i find the time....
How long should a test sample be for it to be long enough to properly test the new algorithm? (and what should we expect to occur with short samples?)

and as a person who generally does 2pass bitrate encodes, what changes should i expect to occur (ssim/psnr/visual changes, etc.)? (as the bitrate won't change like it is in CRF)

[Sharktooth]

if the old method is objectively visually better than the new one i dont see any reason why the new method should replace the old one.
just a couple of point of SSIM score do not justify ANY visual detail loss.
on the other hand, if the new method is visually consistently better than the old one, go on...

[burfadel]

If the lower quality is attributed to a lower bitrate of ~15 percent (may vary) for a given CRF, it sounds reasonable to say that for a set bitrate the quality would be noticeably improved. It would also be reasonable to suggest to patch x264 to increase the bitrate used in CRF mode since you now have some spare, to the point where the image quality is actually improved (and still probably saving some bitrate)! It doesn't matter if the SSIM is reasonably higher in this case, the main point would be the increased quality at a given CRF whilst still saving a few percentage points of quality for most encodes. Complaints only occur if people have to change the CRF they use from say, 24 to 22 to make up the shortfall in quality.

To summarise, regardless of bitrate saving it would be more important to adjust CRF mode so people can use the same settings in CRF mode and have better quality, without using more bitrate!

[audyovydeo]

If the lower quality is attributed to a lower bitrate of ~15 percent (may vary) for a given CRF, it sounds reasonable to say that for a set bitrate the quality would be noticeably improved. It would also be reasonable to suggest to patch x264 to increase the bitrate used in CRF mode since you now have some spare, to the point where the image quality is actually improved (and still probably saving some bitrate)! It doesn't matter if the SSIM is reasonably higher in this case, the main point would be the increased quality at a given CRF whilst still saving a few percentage points of quality for most encodes. Complaints only occur if people have to change the CRF they use from say, 24 to 22 to make up the shortfall in quality.

To summarise, regardless of bitrate saving it would be more important to adjust CRF mode so people can use the same settings in CRF mode and have better quality, without using more bitrate!


Improvements are always welcome.
On the other hand, given the time-consuming process of empirically finding a new CRF value range by each user, the less CRF changes, the better.
As things stand, it would seems wise (as in : user-friendly) to add this new patch as an option, as has been suggested in the earlier post

cheers
audyovydeo

[nurbs]

Well, there is already an --aq-mode option, so I don't see how making this optional can be a problem. Looks like an interesting change. I'll have time to test this at the weekend.

[Dark Shikari]

Well, there is already an --aq-mode option, so I don't see how making this optional can be a problem. Looks like an interesting change. I'll have time to test this at the weekend.Yes, if there are any reasons to keep the old algorithm, I will make both available as --aq-modes.

[Sharktooth]

any news?

[Sagekilla]

I'll try testing this out, because if I can get good visual quality but at lower bitrates (i.e. use a higher CRF using autoVAQ than I did for regular VAQ) then I'd love to see this patch in public builds as an option.

[burfadel]

The AutoVAQ does seem to be much more bitrate friendly! Any loss visually can be compensated with algorithm adjustments, whilst still being automatic based around AQ 1! ... Even with compensation I could envisage a more efficient bitrate usage.

The reason for this statement is setting the CRF with normal AQ to get the same filesize for the same clip with AutoVAQ, using the exact same settings:
--keyint 450 --ref 5 --mixed-refs --bframes 6 --b-adapt 2 --b-pyramid --weightb --direct auto --subme 9 --trellis 2 --psy-rd 1:0.5 --partitions all --8x8dct --me umh --threads 6 --progress --thread-input --no-psnr --no-ssim --nr 500

The AutoVAQ clip had quite noticeably better quality!

Just a thought.

[CruNcher]

@Dark
any motion comparison of it on tuwabo :) ehh thouho dammit thouo ahh you know what i mean :D
also don't you see a chance of getting a visual improvement by finally go some adaptive deadzone approach in the encoder ?

[juGGaKNot]

WOW this is the best i can get out of aq ( i had it on 0 because it looks bad in general with psy rd )

settings :

start "encode" /b /low /max /wait "%myfiles%\x264v.exe" --pass 1 --bitrate %btrate% --stats "%mypath%\@temp\%mymovie%.stats" --level 4.1 --ref 4 --mixed-refs --bframes 4 --b-adapt 2 --weightb --direct auto --deblock -2:-1 --subme 9 --trellis 2 --psy-rd 0:0 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 24000 --vbv-maxrate 24000 --me umh --merange 24 --threads auto --aq-strength 1.0 --sar 1:1 --progress --no-psnr --no-ssim --output NUL "%mypath%\@temp\%mymovie%.avs"
start "encode" /b /low /max /wait "%myfiles%\x264v.exe" --pass 2 --bitrate %btrate% --stats "%mypath%\@temp\%mymovie%.stats" --level 4.1 --ref 4 --mixed-refs --bframes 4 --b-adapt 2 --weightb --direct auto --deblock -2:-1 --subme 9 --trellis 2 --psy-rd 0:0 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 24000 --vbv-maxrate 24000 --me umh --merange 24 --threads auto --aq-strength 1.0 --sar 1:1 --progress --no-psnr --no-ssim --output "%mypath%\@temp\%mymovie%.264" "%mypath%\@temp\%mymovie%.avs"

Bitrate 4500


avis [info]: 1024x576 @ 30.00 fps (1800 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile High, level 4.1
x264 [info]: slice I:24 Avg QP:18.00 size: 36535
x264 [info]: slice P:705 Avg QP:18.28 size: 20664
x264 [info]: slice B:1071 Avg QP:19.03 size: 12306
x264 [info]: consecutive B-frames: 5.6% 31.6% 37.5% 14.0% 11.3%
x264 [info]: mb I I16..4: 16.6% 63.2% 20.3%
x264 [info]: mb P I16..4: 12.3% 36.0% 6.2% P16..4: 25.8% 9.8% 4.3% 0.0% 0
.0% skip: 5.6%
x264 [info]: mb B I16..4: 4.4% 11.0% 2.1% B16..8: 31.2% 3.1% 2.7% direct:
12.1% skip:33.5% L0:43.8% L1:43.5% BI:12.7%
x264 [info]: final ratefactor: 16.70
x264 [info]: 8x8 transform intra:64.9% inter:73.0%
x264 [info]: direct mvs spatial:99.9% temporal:0.1%
x264 [info]: coded y,uvDC,uvAC intra:64.3% 58.9% 11.3% inter:34.2% 30.5% 1.4%
x264 [info]: ref P L0 77.8% 11.3% 6.9% 4.0%
x264 [info]: ref B L0 81.2% 12.1% 6.6%
x264 [info]: kb/s:3816.6

encoded 1800 frames, 2.30 fps, 3816.81 kb/s
avis [info]: 1024x576 @ 30.00 fps (1800 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile High, level 4.1
x264 [info]: slice I:24 Avg QP:18.19 size: 34036
x264 [info]: slice P:705 Avg QP:18.20 size: 23144
x264 [info]: slice B:1071 Avg QP:19.08 size: 14918
x264 [info]: consecutive B-frames: 5.6% 31.6% 37.5% 14.0% 11.3%
x264 [info]: mb I I16..4: 15.4% 68.5% 16.1%
x264 [info]: mb P I16..4: 13.2% 36.5% 5.3% P16..4: 24.0% 10.3% 4.2% 0.0% 0
.0% skip: 6.5%
x264 [info]: mb B I16..4: 4.6% 11.1% 2.0% B16..8: 30.2% 3.7% 2.9% direct:
13.1% skip:32.5% L0:42.1% L1:41.4% BI:16.5%
x264 [info]: 8x8 transform intra:65.4% inter:77.5%
x264 [info]: direct mvs spatial:95.7% temporal:4.3%
x264 [info]: coded y,uvDC,uvAC intra:63.3% 59.2% 10.8% inter:37.1% 30.2% 1.4%
x264 [info]: ref P L0 77.0% 11.9% 7.0% 4.1%
x264 [info]: ref B L0 81.5% 12.2% 6.3%
x264 [info]: kb/s:4414.8

encoded 1800 frames, 2.37 fps, 4415.05 kb/s

Encoding started at 05:50 PM and finished at 06:16 PM


26 minutes, with psy-rd it took 3 hours

Maybe aq is not the problem when it comes to my source and psy rd is.

Without aq :

avis [info]: 1024x576 @ 30.00 fps (1800 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile High, level 4.1
x264 [info]: slice I:24 Avg QP:18.71 size: 36688
x264 [info]: slice P:705 Avg QP:18.81 size: 20726
x264 [info]: slice B:1071 Avg QP:19.45 size: 12345
x264 [info]: consecutive B-frames: 5.6% 31.6% 37.5% 14.0% 11.3%
x264 [info]: mb I I16..4: 21.4% 59.1% 19.5%
x264 [info]: mb P I16..4: 15.2% 33.4% 5.6% P16..4: 26.0% 9.1% 4.3% 0.0% 0
.0% skip: 6.5%
x264 [info]: mb B I16..4: 4.8% 9.7% 2.0% B16..8: 30.4% 3.0% 2.7% direct:
11.4% skip:36.1% L0:43.8% L1:43.5% BI:12.7%
x264 [info]: final ratefactor: 17.54
x264 [info]: 8x8 transform intra:60.7% inter:73.2%
x264 [info]: direct mvs spatial:99.9% temporal:0.1%
x264 [info]: coded y,uvDC,uvAC intra:58.3% 54.1% 10.5% inter:32.4% 29.4% 1.7%
x264 [info]: ref P L0 77.9% 11.3% 6.9% 3.9%
x264 [info]: ref B L0 81.7% 11.9% 6.4%
x264 [info]: kb/s:3828.5

encoded 1800 frames, 1.97 fps, 3828.74 kb/s
avis [info]: 1024x576 @ 30.00 fps (1800 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile High, level 4.1
x264 [info]: slice I:24 Avg QP:18.75 size: 34385
x264 [info]: slice P:705 Avg QP:18.88 size: 23076
x264 [info]: slice B:1071 Avg QP:19.50 size: 14955
x264 [info]: consecutive B-frames: 5.6% 31.6% 37.5% 14.0% 11.3%
x264 [info]: mb I I16..4: 18.7% 66.9% 14.4%
x264 [info]: mb P I16..4: 16.2% 33.8% 4.6% P16..4: 24.0% 9.8% 3.9% 0.0% 0
.0% skip: 7.6%
x264 [info]: mb B I16..4: 4.9% 9.8% 1.8% B16..8: 29.7% 3.5% 2.9% direct:
12.3% skip:35.1% L0:42.3% L1:41.4% BI:16.3%
x264 [info]: 8x8 transform intra:61.3% inter:78.5%
x264 [info]: direct mvs spatial:95.8% temporal:4.2%
x264 [info]: coded y,uvDC,uvAC intra:57.8% 53.5% 10.1% inter:35.2% 29.0% 1.7%
x264 [info]: ref P L0 76.9% 12.0% 7.0% 4.1%
x264 [info]: ref B L0 81.7% 12.0% 6.3%
x264 [info]: kb/s:4414.7

encoded 1800 frames, 2.22 fps, 4414.87 kb/s

When will this be out of "testing".

[nm]

26 minutes, with psy-rd it took 3 hours

Maybe aq is not the problem when it comes to my source and psy rd is.
There is something seriously wrong with psy-rd taking that long.

[Dark Shikari]

Psy-rd should have no significant speed impact.

[juGGaKNot]

There is something seriously wrong with psy-rd taking that long.

Will test more tomorrow, it was 2:1

quality really sucked

Psy-rd should have no significant speed impact.

will see, just saying that aq is not a problem anymore ..

[poisondeathray]

What is the performance hit for using AutoVAQ? If it analyzes on a frame basis, it must have some overhead?

[juGGaKNot]

What is the performance hit for using AutoVAQ? If it analyzes on a frame basis, it must have some overhead?

Its faster by 0.15 FPS on my source, tested with low priority, see my logs.

Also the final ratefactor is 16.70, without autovac its 17.54

[LoRd_MuldeR]

What is the performance hit for using AutoVAQ? If it analyzes on a frame basis, it must have some overhead?

I can't detect a noteworthy speed difference between normal VAQ, AutoVAQ and AQ disabled. This is with both, Psy-RDO and Psy-Trellis, enabled.

[poisondeathray]

Have you done any more testing on that 1st clip Lord Mulder? (the one with the bad results)?

I'll try to do some testing this weekend

[LoRd_MuldeR]

Have you done any more testing on that 1st clip Lord Mulder? (the one with the bad results)?

No, not really. I can only say that AutoVAQ creates significant smaller files at CRF 22 with most of my sources (and bigger files only with a few sources).

This doesn't say anything about the quality of AutoVAQ, but it's an observation worth mentioning anyway...

[Chengbin]

Anybody have opinion on the AutoVAQ patch in terms of quality? Any pictures?

[LoRd_MuldeR]

Anybody have opinion on the AutoVAQ patch in terms of quality? Any pictures?

I did a first test and posted my results here:
http://forum.doom9.org/showpost.php?p=1285122&postcount=6

[MasterNobody]

Chengbin
There are encoded samples (not screenshots) in my first post by which you can compare quality yourself. But if you don't trust me, or your usual sources significantly differ from my test samples than you probably need to test it yourself on usual for you sources (and only after this you could understand would it give better quality FOR YOU or not).

[Fr4nz]

I did a first test and posted my results here:
http://forum.doom9.org/showpost.php?p=1285122&postcount=6

I don't see differences...maybe clips in "action" reveal more?

EDIT: Well, there are indeed some differences, and precisely on the dark background behind the singer...without autovaq the background seems to be more "noisy", which is better at the eyes IMO (so yes, I agree with you Mulder :D).

Anyway, as I stated previously, it would be interesting to see these clips in action and judge which one is the winner.

[LoRd_MuldeR]

Anyway, as I stated previously, it would be interesting to see these clips in action and judge which one is the winner.

In the first post you find clips that you can download an see "in action". I will also upload my test clip...

[komisar]

Some visual comparsion found here: http://komisar.gin.by/avaq/index.html
All result for actions and logs named "All test results in archive: tests.7z (58M)"

[juGGaKNot]

Some visual comparsion found here: http://komisar.gin.by/avaq/index.html
All result for actions and logs named "All test results in archive: tests.7z (58M)"

x264.1153kAVAQ.generic.x32.exe crashes on 2'nd pass

x264_AutoVAQ.02.diff is this the same as in this 1148 build or new ?

[vucloutr]

i got a BSOD + instant reboot on 2nd pass with skystrife's x264.1153M.AutoVAQ.x64.exe.

[Chengbin]

I am by no means have a eagle's eye (I'm actually quite blind compared to you guys). But is it possible to get a lower image quality when you use autovaq?

I did my own test, and the file is about 20% smaller at the same crf value. I can't see a difference.

I'm gonna do a test now with a ridiculously high crf value (30) on autovaq and normal x264 for both encodes so I can spot the quality differences easier.

Why is x264 so much smaller with autovaq? (794KB vs 1MB)

[LoRd_MuldeR]

i got a BSOD + instant reboot on 2nd pass with skystrife's x264.1153M.AutoVAQ.x64.exe.

x264 is running as a normal user-space process. Hence x264 itself may crash, but it cannot cause a BSOD. Something unrelated to x264 is seriously wrong with your system.

Check the stability of your system with Memtest86+ and Prim95. Keep an eye on the CPU temperature...

[LoRd_MuldeR]

I am by no means have a eagle's eye (I'm actually quite blind compared to you guys). But is it possible to get a lower image quality when you use autovaq?

I did my own test, and the file is about 20% smaller at the same crf value. I can't see a difference.

I'm gonna do a test now with a ridiculously high crf value (30) on autovaq and normal x264 for both encodes so I can spot the quality differences easier.

Why is x264 so much smaller with autovaq? (794KB vs 1MB)

First of all CRF doesn't deliver perfect constant quality, it only delivers "similar" quality. Furthermore AutoVAQ changes the meaning of the CRF values!

So there is only one way to do a proper comparison: Do two 2-Pass encodes at the same bitrate, one with AutoVAQ and one with the "normal" AQ algorithm.

Only files of the same size can be compared visually! Comparing files of different sizes doesn't lead anywhere...

[kumi]

Are comparisons of 2 equally-sized CRF encodes also valid?

[Dark Shikari]

Are comparisons of 2 equally-sized CRF encodes also valid?Yes, that's probably even better.

[LoRd_MuldeR]

Here is the sample I used for my first post:
* http://www.rapidspread.com/file.jsp?id=gzhurhg70n
* http://www.rapidspread.com/file.jsp?id=f9wzkp5iu2
* http://www.rapidspread.com/file.jsp?id=bp0inkxhj0
* http://www.rapidspread.com/file.jsp?id=4yduqmzzde

[burfadel]

From a comment line in the AutoVAQ patch:

constants chosen to result in approximately the same overall bitrate as without AQ.


That means that autovaq is optimised to produce file sizes similar to what is possible WITHOUT VAQ enabled at all. When VAQ was introduced it actually increased the file size for a given CRF.

Autovaq code can be adjusted to represent a final output size closer to that of the current VAQ (with higher quality supposedly). I think VAQ should be adjust to represented roughly a half way point between with and without VAQ, which should give a better picture whilst still resulting in a smaller file size (in CRF mode).

I think the next great step would be auto psy-rd/psy-trellis, the more complex the scene is the more it benefits from a higher value for each (to a certain extent). An autoPSY (ok, maybe not the best name for it!) would be helpful so adjustments for each encoding wouldn't be necessary, in addition to being very beneficial inside the same encode. A bright, complex detail wise scene could use --psy-rd 1.0:0.6 say as a base, and a flat scene, of which anime is very flat, can almost be turned completely off. --psy-rd function can be used as a basis, and it could be turned off (so its fixed as the values state) with a --noauto-psyrd command (for example).

[vucloutr]

x264 is running as a normal user-space process. Hence x264 itself may crash, but it cannot cause a BSOD. Something unrelated to x264 is seriously wrong with your system.

Check the stability of your system with Memtest86+ and Prim95. Keep an eye on the CPU temperature...
ok, i did not knew that (my sys worked without problems so far).
so i set all back to defaults and the 2nd pass went fine.

[LoRd_MuldeR]

ok, i did not knew that (my sys worked without problems so far).

x264 puts heavy load on your CPU. And that for a very long time. Hence an unstable system can crash easily, even if you didn't encounter problems before.

Still this isn't a problem with x264 itself, but a problem with your hardware...