x264 "Macroblock Tree Ratecontrol" testing (committed)

[Audionut]

Originally Posted by juGGaKNot

lookahead 200 crashed ( 236 frames source )

http://forum.doom9.org/showthread.ph...00#post1311000

Originally Posted by Dark Shikari

All crashes that I've seen so far that occurred with very large --lookahead values traced back perfectly to x264_malloc, so you should check with gdb before reporting such issues as bugs.

Originally Posted by Snowknight26

Couldn't get 64-bit x264+avs2yuv working with gdb but nevertheless, seems you were right:

[Firebird]

First test. Source is anime (Suzumiya Haruhi-chan Op)
(Tested on AMD athlon XP 1700, lol)

"D:\Program Files\megui\tools\x264\x264.exe" --profile high --crf 18.0 --keyint 240 --min-keyint 24 --ref 8 --no-fast-pskip --bframes 5 --b-adapt 2 --no-weightb --direct auto --subme 9 --trellis 2 --psy-rd 0.3:0 --partitions p8x8,b8x8,i4x4,i8x8 --me umh --thread-input --aq-strength 0.5 --psnr --ssim --output "E:\haruhi\haruhi op.mkv" "E:\haruhi\haruhi op.avs"

avis [info]: 720x480 @ 23.98 fps (1476 frames)
x264 [info]: using cpu capabilities: MMX2
x264 [info]: profile High, level 3.1

x264 [info]: slice I:34 Avg QP:17.37 size: 25881 PSNR Mean Y:51.48 U:53.35 V:52.78 Avg:51.45 Global:48.29
x264 [info]: slice P:667 Avg QP:20.04 size: 11522 PSNR Mean Y:47.32 U:49.74 V:49.10 Avg:47.77 Global:45.49
x264 [info]: slice B:775 Avg QP:23.48 size: 5286 PSNR Mean Y:45.22 U:47.57 V:46.88 Avg:45.76 Global:43.84
x264 [info]: consecutive B-frames: 12.8% 43.0% 20.6% 10.3% 10.1% 3.3%
x264 [info]: mb I I16..4: 41.1% 29.0% 29.9%
x264 [info]: mb P I16..4: 6.9% 8.1% 5.2% P16..4: 30.2% 10.2% 6.9% 0.0% 0.0% skip:32.4%
x264 [info]: mb B I16..4: 1.3% 1.6% 0.7% B16..8: 27.2% 4.3% 4.5% direct: 4.5% skip:55.9% L0:41.5% L1:47.4% BI:11.1%
x264 [info]: 8x8 transform intra:38.5% inter:47.9%
x264 [info]: direct mvs spatial:99.4% temporal:0.6%
x264 [info]: coded y,uvDC,uvAC intra:47.5% 68.4% 47.8% inter:16.9% 22.8% 9.0%
x264 [info]: ref P L0 59.8% 13.8% 8.2% 4.9% 4.4% 3.6% 2.4% 2.9%
x264 [info]: ref B L0 68.3% 12.8% 7.1% 4.9% 2.9% 2.6% 1.5%
x264 [info]: SSIM Mean Y:0.9933523
x264 [info]: PSNR Mean Y:46.313 U:48.684 V:48.016 Avg:46.798 Global:44.586 kb/s:1645.44
encoded 1476 frames, 1.69 fps, 1645.67 kb/s

With mbtree:

avis [info]: 720x480 @ 23.98 fps (1476 frames)
x264 [info]: using cpu capabilities: MMX2
x264 [info]: profile High, level 3.1

x264 [info]: slice I:34 Avg QP:16.10 size: 31193 PSNR Mean Y:52.56 U:54.01 V:53.48 Avg:52.51 Global:50.16
x264 [info]: slice P:660 Avg QP:20.11 size: 12298 PSNR Mean Y:47.53 U:49.85 V:49.34 Avg:48.00 Global:46.47
x264 [info]: slice B:782 Avg QP:24.08 size: 6384 PSNR Mean Y:45.86 U:48.21 V:47.57 Avg:46.40 Global:45.32
x264 [info]: consecutive B-frames: 12.0% 43.6% 20.2% 10.8% 9.7% 3.7%
x264 [info]: mb I I16..4: 41.3% 28.6% 30.2%
x264 [info]: mb P I16..4: 6.4% 8.0% 5.5% P16..4: 28.7% 10.0% 6.8% 0.0% 0.0% skip:34.7%
x264 [info]: mb B I16..4: 1.3% 1.7% 0.9% B16..8: 25.4% 4.7% 4.7% direct: 4.3% skip:57.0% L0:43.6% L1:44.5% BI:11.9%
x264 [info]: 8x8 transform intra:38.6% inter:46.9%
x264 [info]: direct mvs spatial:98.1% temporal:1.9%
x264 [info]: coded y,uvDC,uvAC intra:48.5% 68.8% 48.7% inter:16.9% 22.0% 9.6%
x264 [info]: ref P L0 56.5% 15.0% 9.0% 5.3% 4.8% 4.1% 2.1% 3.3%
x264 [info]: ref B L0 68.1% 13.1% 7.1% 4.6% 3.5% 2.3% 1.3%
x264 [info]: SSIM Mean Y:0.9944401
x264 [info]: PSNR Mean Y:46.763 U:49.077 V:48.494 Avg:47.259 Global:45.874 kb/s:1841.39
encoded 1476 frames, 1.55 fps, 1841.62 kb/s

[DarkZell666]

@Firebird : don't use CRF for doing such tests, go for two-pass (either bitrate or filesize, it doesn't matter), otherwise the results are meaningless x_x". Especially since Dark Shikari mentionned CRF was redefined. This means for any given CRF value, the expected bitrate will change for the same source. You won't know if the SSIM increase is due to the CRF redifinition or to the MB Tree Ratecontrol algo, and you won't know if the +0.0011 SSIM increase was worth the 204kbps increase.

[Firebird]

Sorry, my fault.

The same source, with very low bitrate.

"D:\Program Files\megui\tools\x264\x264.exe" --profile high --pass 2 --bitrate 272 --stats "E:\haruhi\haruhi op.stats" --keyint 240 --min-keyint 24 --ref 8 --no-fast-pskip --bframes 5 --b-adapt 2 --no-weightb --direct auto --subme 9 --trellis 2 --psy-rd 0.0:0 --partitions p8x8,b8x8,i4x4,i8x8 --me umh --thread-input --aq-strength 0.5 --psnr --ssim --output "E:\haruhi\haruhi op.mkv" "E:\haruhi\haruhi op cl 264.avs"

First pass:

avis [info]: 720x480 @ 23.98 fps (1476 frames)
x264 [info]: using cpu capabilities: MMX2
x264 [info]: profile Main, level 3.0

x264 [info]: slice I:34 Avg QP:39.30 size: 4834 PSNR Mean Y:36.49 U:43.22 V:42.39 Avg:37.44 Global:32.02
x264 [info]: slice P:680 Avg QP:42.17 size: 1988 PSNR Mean Y:30.98 U:38.60 V:37.64 Avg:32.21 Global:29.17
x264 [info]: slice B:762 Avg QP:44.72 size: 726 PSNR Mean Y:29.43 U:37.02 V:35.92 Avg:30.67 Global:28.19
x264 [info]: consecutive B-frames: 13.9% 43.1% 19.6% 12.5% 7.6% 3.3%
x264 [info]: mb I I16..4: 84.9% 0.0% 15.1%
x264 [info]: mb P I16..4: 24.6% 0.0% 0.0% P16..4: 15.8% 0.0% 0.0% 0.0% 0.0% skip:59.6%
x264 [info]: mb B I16..4: 3.8% 0.0% 0.0% B16..8: 13.1% 0.0% 0.0% direct: 4.3% skip:78.9% L0:41.4% L1:56.8% BI: 1.7%
x264 [info]: final ratefactor: 39.49
x264 [info]: direct mvs spatial:96.6% temporal:3.4%
x264 [info]: coded y,uvDC,uvAC intra:12.0% 40.7% 17.8% inter:1.5% 7.3% 1.3%
x264 [info]: SSIM Mean Y:0.8703792
x264 [info]: PSNR Mean Y:30.307 U:37.893 V:36.858 Avg:31.533 Global:28.676 kb/s:268.94
encoded 1476 frames, 7.77 fps, 269.17 kb/s

Second pass:

avis [info]: 720x480 @ 23.98 fps (1476 frames)
x264 [info]: using cpu capabilities: MMX2
x264 [info]: profile High, level 3.1

x264 [info]: slice I:34 Avg QP:35.68 size: 5261 PSNR Mean Y:39.15 U:44.12 V:43.20 Avg:39.67 Global:35.20
x264 [info]: slice P:680 Avg QP:39.40 size: 2009 PSNR Mean Y:34.56 U:40.01 V:38.85 Avg:35.51 Global:33.56
x264 [info]: slice B:762 Avg QP:41.76 size: 726 PSNR Mean Y:33.13 U:38.31 V:36.86 Avg:34.08 Global:32.43
x264 [info]: consecutive B-frames: 13.9% 43.1% 19.6% 12.5% 7.6% 3.3%
x264 [info]: mb I I16..4: 41.5% 47.9% 10.6%
x264 [info]: mb P I16..4: 10.0% 9.1% 1.1% P16..4: 24.7% 3.3% 1.6% 0.0% 0.0% skip:50.2%
x264 [info]: mb B I16..4: 1.2% 0.8% 0.0% B16..8: 19.5% 0.5% 0.3% direct: 0.5% skip:77.1% L0:49.2% L1:49.8% BI: 1.1%
x264 [info]: 8x8 transform intra:45.0% inter:77.3%
x264 [info]: direct mvs spatial:75.7% temporal:24.3%
x264 [info]: coded y,uvDC,uvAC intra:14.6% 32.7% 12.8% inter:2.2% 5.2% 0.7%
x264 [info]: ref P L0 54.4% 16.7% 10.5% 5.6% 5.5% 2.9% 2.1% 2.4%
x264 [info]: ref B L0 66.4% 13.3% 7.4% 3.8% 4.4% 2.9% 1.7%
x264 [info]: SSIM Mean Y:0.9407777
x264 [info]: PSNR Mean Y:33.928 U:39.227 V:37.926 Avg:34.866 Global:32.970 kb/s:272.70
encoded 1476 frames, 3.02 fps, 272.93 kb/s

With mbtree:

First pass:

avis [info]: 720x480 @ 23.98 fps (1476 frames)
x264 [info]: using cpu capabilities: MMX2
x264 [info]: profile Main, level 3.0

x264 [info]: slice I:33 Avg QP:38.49 size: 5475 PSNR Mean Y:36.39 U:43.41 V:42.54 Avg:37.50 Global:33.86
x264 [info]: slice P:670 Avg QP:43.89 size: 1958 PSNR Mean Y:30.81 U:38.71 V:37.73 Avg:32.07 Global:29.60
x264 [info]: slice B:773 Avg QP:46.00 size: 752 PSNR Mean Y:29.75 U:37.36 V:36.18 Avg:31.01 Global:28.85
x264 [info]: consecutive B-frames: 13.7% 40.5% 21.2% 11.9% 9.4% 3.3%
x264 [info]: mb I I16..4: 81.6% 0.0% 18.4%
x264 [info]: mb P I16..4: 23.4% 0.0% 0.0% P16..4: 14.1% 0.0% 0.0% 0.0% 0.0% skip:62.5%
x264 [info]: mb B I16..4: 3.7% 0.0% 0.0% B16..8: 13.2% 0.0% 0.0% direct: 3.9% skip:79.1% L0:43.4% L1:54.6% BI: 2.1%
x264 [info]: final ratefactor: 40.39
x264 [info]: direct mvs spatial:95.2% temporal:4.8%
x264 [info]: coded y,uvDC,uvAC intra:12.3% 41.9% 18.5% inter:1.4% 6.8% 1.2%
x264 [info]: SSIM Mean Y:0.8832674
x264 [info]: PSNR Mean Y:30.382 U:38.107 V:37.027 Avg:31.632 Global:29.246 kb/s:269.44
encoded 1476 frames, 7.06 fps, 269.68 kb/s

Second pass:

avis [info]: 720x480 @ 23.98 fps (1476 frames)
x264 [info]: using cpu capabilities: MMX2
x264 [info]: profile High, level 3.1

x264 [info]: slice I:33 Avg QP:37.28 size: 5388 PSNR Mean Y:37.39 U:43.97 V:43.14 Avg:38.41 Global:35.35
x264 [info]: slice P:670 Avg QP:40.64 size: 2023 PSNR Mean Y:34.47 U:40.15 V:39.04 Avg:35.42 Global:33.84
x264 [info]: slice B:773 Avg QP:43.18 size: 745 PSNR Mean Y:33.24 U:38.47 V:37.01 Avg:34.20 Global:32.76
x264 [info]: consecutive B-frames: 13.7% 40.5% 21.2% 11.9% 9.4% 3.3%
x264 [info]: mb I I16..4: 35.9% 52.8% 11.3%
x264 [info]: mb P I16..4: 9.7% 9.1% 1.3% P16..4: 23.9% 3.2% 1.5% 0.0% 0.0% skip:51.2%
x264 [info]: mb B I16..4: 1.3% 0.9% 0.0% B16..8: 18.9% 0.6% 0.3% direct: 0.5% skip:77.5% L0:50.6% L1:48.4% BI: 1.0%
x264 [info]: 8x8 transform intra:46.3% inter:77.9%
x264 [info]: direct mvs spatial:76.3% temporal:23.7%
x264 [info]: coded y,uvDC,uvAC intra:14.0% 33.0% 13.1% inter:2.2% 5.2% 0.8%
x264 [info]: ref P L0 54.0% 16.4% 10.9% 6.1% 5.2% 2.7% 2.0% 2.6%
x264 [info]: ref B L0 65.6% 13.9% 7.7% 4.0% 4.2% 2.9% 1.8%
x264 [info]: SSIM Mean Y:0.9440372
x264 [info]: PSNR Mean Y:33.892 U:39.353 V:38.070 Avg:34.849 Global:33.264 kb/s:274.15
encoded 1476 frames, 2.96 fps, 274.39 kb/s

[Chengbin]

Seems like a wonderful patch.

Can you explain "redefined" CRF? At the same CRF value, which build give the better quality?

Your links don't work (that directs to mirror05.x264.nl)

[Dark Shikari]

Originally Posted by Chengbin

Seems like a wonderful patch.

Can you explain "redefined" CRF? At the same CRF value, which build give the better quality?

Your links don't work (that directs to mirror05.x264.nl)

mirror05 is down, blame jarod. There's an alternative download link a few posts down.

"Redefining CRF" means that CRF's measure of quality changes, so some videos may have higher or lower bitrates at the same CRF.

[juGGaKNot]

Originally Posted by juGGaKNot

x264_x86_r1195_juGGaKNot
GCC 4.4.0 generic, fprofiled, patched

Source: x264 GIT

Applied patches :

x264_win_zone_parse_fix_05.diff
x264_Macroblock_Tree_Ratecontrol_01.diff

Please check Doom9.org patches thread, Doom9.org Macroblock tree Ratecontrol thread and GIT shortlog for more info.

Compiled by juGGaKNot on August 03-2009, 11:20:00 GMT with GCC 4.4.0 on Windows XP SP-2 32-bit.

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

Originally Posted by Chengbin

Your links don't work (that directs to mirror05.x264.nl)

You can try that ...

[popper]

just a random thought,when i looked at your tree picture in the OP i got to wondering if you have a way to visualise and track pattens in the algorithm(s) your using,
and that in turn reminded me of this old news post
http://www.physorg.com/news138893926.html
" Model helps computers sort data more like humans
August 25th, 2008

MIT associate professor Josh Tenenbaum and his former student, Charles Kemp, have developed a computer algorithm that can select the best type of structure to fit a set of data. Such structures, shown here, include linear order, rings and clusters. Image courtesy / Charles Kemp

....
The model considers a range of possible data structures, such as trees, linear orders, rings, dominance hierarchies, clusters, etc. It finds the best-fitting structure of each type for a given data set and then picks the type of structure that best represents the data.

..."


i just wonder if anyone knows any more about the Tenenbaum/Kemp code algorithm since last year, and if any of its usable here in x264 POC code!

its good to see some experimentation in the algorithms used here and i wonder what drives the devs to try one algorithm against another, and if they measure and trial a given set of POC code just to see if its faster,better,more accurate than another set etc, and if so has there been any push/atemp to see visual pattens as per the above modelhelpsco.jpg appearing in any of these datasets/tests that may lead to even better ways to improve and add new code to the main codebase later...

[Dark Shikari]

Updated version in topic to 0.11. VBV now supported.

[G_M_C]

Originally Posted by Dark Shikari

Updated version in topic to 0.11. VBV now supported.

That's faster than i hoped for. I make clips (AVCHD) for my STD, and i wanted to wait for VBV to added before i started testing. Lets see if it works on my STD

[juGGaKNot]

x264_x86_r1195_juGGaKNot
GCC 4.4.0 generic, fprofiled, patched

Source: GIT

Applied patches :

x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.15_interlace.diff
x264_Macroblock_Tree_Ratecontrol_011.diff

Please check Doom9.org patches thread, Doom9.org Macroblock tree Ratecontrol thread and GIT shortlog for more info.

Compiled by juGGaKNot on August 04-2009, 12:20:00 GMT with GCC 4.4.0 on Windows XP SP-2 32-bit.

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

[imk]

http://imk.cx/junk/x264_mbtree.7z
Updated with v0.11 of patch.

[G_M_C]

Originally Posted by imk

http://imk.cx/junk/x264_mbtree.7z
Updated with v0.11 of patch.

Wich patches did u use ? HRD by any chance ?

[IgorC]

I remember there was a fixed version of SSIM avisynth plugin 0.24a. (with lumimask true)

dunno about behavior x264's internal SSIM.

[imk]

Originally Posted by G_M_C

Wich patches did u use ? HRD by any chance ?

No. Since this is for testing mbtree, the only patches I used were my ICC patch and the mbtree patch.

[Chengbin]

This patch significantly changed CRF (unless compressibility has significantly gone up).

I encoded both videos with CRF 18, same settings.

With mbtree:1366Kbps
Without mbtree:878Kbps

This was done with anime.

So the new CRF 18 should be 15-16?

[Dark Shikari]

Originally Posted by Chengbin

This patch significantly changed CRF (unless compressibility has significantly gone up).

I encoded both videos with CRF 18, same settings.

With mbtree:1366Kbps
Without mbtree:878Kbps

This was done with anime.

So the new CRF 18 should be 15-16?

Again, as I've said at least a dozen times now, the patch redefines CRF, so different sources will get higher or lower bitrates!

Your source is not every source, and I am not going to customize x264 to match your source at the expense of everything else.

[G_M_C]

Originally Posted by G_M_C

Wich patches did u use ? HRD by any chance ?

Originally Posted by juGGaKNot

x264_x86_r1195_juGGaKNot
GCC 4.4.0 generic, fprofiled, patched

Source: GIT

Applied patches :

x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.15_interlace.diff
x264_Macroblock_Tree_Ratecontrol_011.diff

Please check Doom9.org patches thread, Doom9.org Macroblock tree Ratecontrol thread and GIT shortlog for more info.

Compiled by juGGaKNot on August 04-2009, 12:20:00 GMT with GCC 4.4.0 on Windows XP SP-2 32-bit.

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

Originally Posted by Dark Shikari

Again, as I've said at least a dozen times now, the patch redefines CRF, so different sources will get higher or lower bitrates!

[...]

Well my first test is allmost done. Made a 20 minutes reencode of a docu i capped from BBCHD. Will put it on BD9, so i've used juGGaKNot build with HRD.

For testing purposes i've enabled 2-pass mode with both --ssim and --psnr. Will paste results tomorrow, after i've done test no2 (the one without --mbtree (which will be the only difference in the commandline/source etc. used).

This test will also test if --mbtree is accepted by STD's like my Panasonic BD30 (and incidentily if the mbtree patch coincides with the other patches juGGaKNot used, like the hrd-patch).

[Chengbin]

Originally Posted by Dark Shikari

Again, as I've said at least a dozen times now, the patch redefines CRF, so different sources will get higher or lower bitrates!

Your source is not every source, and I am not going to customize x264 to match your source at the expense of everything else.

That's not what I meant. What I was trying to say is, if this patch reduces bitrate by 35% with the same CRF value, it should say something like lower CRF value by (say 2) to compensate for this patch, not just vaguely stating it redefines CRF.

[Dark Shikari]

Originally Posted by Chengbin

That's not what I meant. What I was trying to say is, if this patch reduces bitrate by 50% with the same CRF value, it should say something like lower CRF value by (say 2) to compensate for this patch, not just vaguely stating it redefines CRF.

Please stop responding to my posts without reading them.