VAQ 2.0 Alpha Testing

[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: