[New patch] Improved multi-hexagon search

[Terranigma]

I'm sorry, but when I input that, it gives me an error.
http://img62.imageshack.us/img62/4698/hadamarderrorbp3.png

[Dark Shikari]

imho it's now --fpel-cmpThat's a really bad commandline IMO (if its a boolean); it says nothing about what it does. If it was a string-based commandline like --fpel-cmp sad vs --fpel-cmp satd, that would be fine though.

[Terranigma]

Thanks Dark Shikari, it now works. The user before me did'nt specify that i'd have to enter in sad or satd after the command. :)

[Dark Shikari]

Thanks Dark Shikari, it now works. The user before me did'nt specify that i'd have to enter in sad or satd after the command. :)Hah, so apparently we were thinking the same thing about the commandlines :p:)

[DeathTheSheep]

Cef, how exactly did you get these patches to work?
In Msys, trying: patch -u -p1 < imh.diff (or some others) throws errors and doesn't patch x264.c or x264.h! (and akupenguin's patch works but doesn't find the files to patch, so I have to specify the directories of each file individually).

What program do you use? What commandline?

[Unearthly]

Ok, so I gave up compiling with VS as it just wouldn't do SATD ESA right (crashed every time). I installed cygwin and got a build with the:
-SATD (hadamard)
-IMH
-New subme7
-me-prepass
patches.

Compiled with pthreads, SSSE3, but no mp4, gpac was not working and I don't feel like fighting it at the moment.

http://rapidshare.com/files/55808006/x264.zip.html

Giant merged patch (for SVN 675) included in the zip.

Going to test some of these new options overnight now.

[foxyshadis]

Did you guys replace if(bcost < 100) with if(bcost < SAD_THRESH(100))? I forgot to do that in the patch I put up. You'll have to double-define x264_pixel_size_shift or raise its scope though.

[Dark Shikari]

Did you guys replace if(bcost < 100) with if(bcost < SAD_THRESH(100))? I forgot to do that in the patch I put up.
Yeah, that should be fixed. I'm not sure if I updated my patch with that. It gives a small quality boost, and more importantly, its more correct.

[Unearthly]

It's not in the patch in the first post. Also, SAD_THRESH requires 'x264_pixel_size_shift'. Is this:

static const int x264_pixel_size_shift[7] = { 0, 1, 1, 2, 3, 3, 4 };

the right one? (It's the only one I saw.)

[Dark Shikari]

It's not in the patch in the first post. Also, SAD_THRESH requires 'x264_pixel_size_shift'. Is this:

static const int x264_pixel_size_shift[7] = { 0, 1, 1, 2, 3, 3, 4 };

the right one? (It's the only one I saw.)Yup, that's it.

Basically what that matrix does is shift 100 by the correct value depending on what size partition the motion estimation function is dealing with.

If you use (bcost < 100), that applies far more strongly to 4x4 blocks, for example, than 16x16 blocks. SAD_THRESH(100) divides by 16, for example, when dealing with 4x4 blocks, since they're 16 times smaller.

[Unearthly]

Updated the link in my post with the new build and patch.

[Dark Shikari]

One slight problem it seems... IMH is listed above UMH on x264 --longhelp. Not sure if this was my mistake or someone else's.

Right now it is

DIA
HEX
IMH
UMH
ESA

which implies that IMH is faster than UMH, which its not. It should be flipped.

[Unearthly]

My mistake, due to some manual merging (start using svn diff's and it won't happen again ;) ). Though anyone downloading this experimental build should know the difference.

[Dark Shikari]

My mistake, due to some manual merging (start using svn diff's and it won't happen again ;) ). Though anyone downloading this experimental build should know the difference.What's the best way to use svn diff? I'm not really familiar with svn except in terms of the usual downloading source from svn, so what commandline would I use?

[Unearthly]

I use TortoiseSVN on Windows which has a 'Create Patch' option, it seems the CLI equivalent would be:

svn diff >mypatch.diff

That will create a patch for all of your changed files in the directory. I'm not sure if there is an easy way to pick and choose which files to patch using CLI though, maybe someone else can help with that.

[Dark Shikari]

I use TortoiseSVN on Windows which has a 'Create Patch' option, it seems the CLI equivalent would be:

svn diff >mypatch.diff

That will create a patch for all of your changed files in the directory. I'm not sure if there is an easy way to pick and choose which files to patch using CLI though, maybe someone else can help with that.One reason why I like regular diff is because I can very easily remove sections from it... because often the diff has far, far more things in it than I actually want to be in the patch :p

My programming organization is a complete mess.

[DeathTheSheep]

due to some manual merging (start using svn diff's and it won't happen again ).

This. ;)

[foxyshadis]

It's the same unified diff, you can still remove chunks, the headers are just a bit different. I can mostly get away with just swapping out the headers, in fact, though sometimes line numbers need fudging.

[DeathTheSheep]

Header editing, I see. Having no clue what to swap with what, manual editing is the way to go for me. Which takes some time. :)

Dark Shikari, what's the best way to apply your patches (i.e. what works for you without manually editing in some of the code)?

[Unearthly]

One reason why I like regular diff is because I can very easily remove sections from it... because often the diff has far, far more things in it than I actually want to be in the patch :p

My programming organization is a complete mess.

The only difference I know for sure is the header:

Index: common/common.c
===================================================================
--- common/common.c (revision 675)
+++ common/common.c (working copy)

The actual contents of the diff should be the same, though your diffs often didn't match the SVN source so I thought it might have to do with your different patch creator.

So you can edit them just the same. Just be careful manually editing in case the start line/number of lines change, because then if they aren't right the patch won't work. Removing whole sections should always work though.

[Sharktooth]

that's called unified diff... the header tells what files are changed so the patch can be applied to all the files.
add -u switch to enable the unified diff creation

http://en.wikipedia.org/wiki/Diff#Unified_format

[DeathTheSheep]

In the mean time, could someone apply all the patches to the source code and upload that patched code? I'd like to take a look at things when they're all laid out in one source. :)

[Dark Shikari]

Anyways, here's some statistics on the new version.

Source: The very difficult wire scene of Elephant's Dream, 1001 frames, 1280x720.

Commandline:
x264_new --bframe 16 --b-pyramid --me imh --threads 2 --thread-input --me-prepass --ref 4 --mixed-refs --merange 16 --subme 7 --b-rdo --trellis 2 --bime --weightb --partitions all --direct auto --8x8dct --no-fast-pskip --crf 20

SSIM: 0.9761527
OPSNR: 41.918
Bitrate: 5764.82
FPS: 1.16
Improvement: 3.4%

Commandline:
x264_new --bframe 16 --b-pyramid --me imh --threads 2 --thread-input --ref 4 --mixed-refs --merange 16 --subme 7 --b-rdo --trellis 2 --bime --weightb --partitions all --direct auto --8x8dct --no-fast-pskip --crf 20

SSIM: 0.9753538
OPSNR: 41.782
Bitrate: 5697.25
FPS: 1.39
Improvement: 1.24%

Commandline:
x264_new --bframe 16 --b-pyramid --me umh --me-prepass --threads 2 --thread-input --ref 4 --mixed-refs --merange 16 --subme 7 --b-rdo --trellis 2 --bime --weightb --partitions all --direct auto --8x8dct --no-fast-pskip --crf 20

SSIM: 0.9761320
OPSNR: 41.919
Bitrate: 5788.20
FPS: 1.32
Improvement: 2.9%

Commandline:
x264_new --bframe 16 --b-pyramid --me umh --threads 2 --thread-input --ref 4 --mixed-refs --merange 16 --subme 7 --b-rdo --trellis 2 --bime --weightb --partitions all --direct auto --8x8dct --no-fast-pskip --crf 20

SSIM: 0.9753368
OPSNR: 41.784
Bitrate: 5727.27
FPS: 1.61
Improvement: 0.64%

Commandline:
x264_old --bframe 16 --b-pyramid --me imh --threads 2 --thread-input --me-prepass --ref 4 --mixed-refs --merange 16 --subme 7 --b-rdo --trellis 2 --bime --weightb --partitions all --direct auto --8x8dct --no-fast-pskip --crf 20

SSIM: 0.9752701
OPSNR: 41.774
Bitrate: 5748.29
FPS: 1.6

Interesting: I'm surprised how effective --me-prepass was. The completely free --subme 7 optimization is nice too. :)

--me-prepass should be the most useful in scenes with complex motion: if the various predictors are very far apart, it will vastly improve x264's choice of which predictor to use.

[vortex_hl]

I'm sorry, but when I input that, it gives me an error.
http://img62.imageshack.us/img62/4698/hadamarderrorbp3.png
That's a really bad commandline IMO (if its a boolean); it says nothing about what it does. If it was a string-based commandline like --fpel-cmp sad vs --fpel-cmp satd, that would be fine though.
Thanks Dark Shikari, it now works. The user before me did'nt specify that i'd have to enter in sad or satd after the command. :)

sorry. i thought you will look x264 --help page before use --fpel-cmp function.

[Cef]

new (http://mirror05.x264.nl/Cef/force.php?file=./x264_x86_dark.7z) build (http://mirror05.x264.nl/Cef/force.php?file=./x264_x64_dark.7z) with akupenguin's new satd fpel patch (I used .11 version), see this post (http://forum.doom9.org/showthread.php?p=1045280#post1045280).
previous build was crashing with --fpel-cmp satd anyway :p so please update if you have dl'd it.
rev676 is also up.

[Terranigma]

new (http://mirror05.x264.nl/Cef/force.php?file=./x264_x86_dark.7z) build (http://mirror05.x264.nl/Cef/force.php?file=./x264_x64_dark.7z) with akupenguin's new satd fpel patch (I used .11 version), see this post (http://forum.doom9.org/showthread.php?p=1045280#post1045280).
previous build was crashing with --fpel-cmp satd anyway :p so please update if you have dl'd it.
rev676 is also up.
Thanks Cef, you're the best :)
I liked how you used the word "new" for one version, and "build" for the other one. =P

[DeathTheSheep]

Say, Cef, you still wouldn't mind 7zipping a source package for me (since the patches are giving me qualms), right? :)

[Dark Shikari]

Oh, also, --me-prepass not surprisingly is not beneficial with --me esa :p

It raises bitrate and quality, but for --me esa it can't get enough quality to make up for its bitrate increase. For all other motion search modes, the quality it gains is far more worthwhile.

[Dark Shikari]

I see --me esa now works with --threads in rev 676... can this be added to the patch here, to work with --fpel-cmp sad and satd?

[DeathTheSheep]

Yes. I tried it. :)

[DeathTheSheep]

Oh, also, --me-prepass not surprisingly is not beneficial with --me esa :p

It raises bitrate and quality, but for --me esa it can't get enough quality to make up for its bitrate increase. For all other motion search modes, the quality it gains is far more worthwhile.

I found the opposite results to be true for me: SSIM decreased a negligible amount, while filesize decreased over 1% for my high-motion animated source... And this is with very high merange satd sea.

Cheers!

[Dark Shikari]

I found the opposite results to be true for me: SSIM decreased a negligible amount, while filesize decreased over 1% for my high-motion animated source... And this is with very high merange satd sea.

Cheers!
Now that's very interesting.

It could be the high motion; in one sense --me-prepass considerably increases the effective MERange of the motion estimation algorithm, so that would boost the effectiveness of SATD SEA in cases where high --merange would increase its effectiveness a lot.

[Cef]

Say, Cef, you still wouldn't mind 7zipping a source package for me (since the patches are giving me qualms), right? :)

Here you go (http://mirror05.x264.nl/Cef/force.php?file=./x264_src_dark.7z)

[St Devious]

Wow man , some nice work by u here . especially for me since i always use subme 7 coz time is not as big a factor as quality. Keep improving the algo's .

Try other things which can improve quality too .

when is the build including this update for subme 7 coming ?

[Sagekilla]

Hey, is there a patched and compiled build with all the goodies we have so far yet? I'd love to try it out after my little hiatus on encoding the past week.

[martino]

Here is are some test encodes that I run this afternoon. Hopefully they'll be of some help. This was done on a Core 2 Duo E6750 @ 2.67GHz (stock frequency).

Kenkou Zenrakei Suieibu Umisho (EP11) Anime 704x400 23.976fps - first 4000 frames

--qp 18 --ref 8 --mixed-refs --no-fast-pskip --bframes 5 --b-pyramid --b-rdo --bime --weightb --direct auto --subme 7 --trellis 2 --analyse all --8x8dct --me umh --merange 24 --threads auto
avis [info]: 704x400 @ 23.98 fps (4000 frames)
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSSE3
x264 [info]: slice I:48 Avg QP:15.00 size: 25415 PSNR Mean Y:53.75 U:54.82 V:54.87 Avg:54.02 Global:52.68
x264 [info]: slice P:2053 Avg QP:18.00 size: 8066 PSNR Mean Y:48.81 U:49.73 V:50.03 Avg:49.07 Global:48.74
x264 [info]: slice B:1899 Avg QP:19.74 size: 2692 PSNR Mean Y:47.55 U:49.28 V:49.49 Avg:48.01 Global:47.76
x264 [info]: mb I I16..4: 30.5% 41.6% 27.9%
x264 [info]: mb P I16..4: 7.2% 7.4% 2.3% P16..4: 31.0% 9.5% 3.7% 0.4% 0.3% skip:38.2%
x264 [info]: mb B I16..4: 0.1% 0.2% 0.1% B16..8: 14.9% 1.4% 3.4% direct: 4.5% skip:75.3%
x264 [info]: 8x8 transform intra:43.7% inter:42.6%
x264 [info]: direct mvs spatial:99.2% temporal:0.8%
x264 [info]: ref P 68.7% 13.5% 6.7% 3.5% 2.4% 2.1% 1.8% 1.4%
x264 [info]: ref B 77.6% 11.3% 3.9% 2.2% 1.5% 1.5% 1.2% 0.9%
x264 [info]: SSIM Mean Y:0.9947880
x264 [info]: PSNR Mean Y:48.270 U:49.581 V:49.835 Avg:48.624 Global:48.270 kb/s:1097.76
11.90 fps
1097.87 kb/s


--qp 18 --ref 8 --mixed-refs --no-fast-pskip --bframes 5 --b-pyramid --b-rdo --bime --weightb --direct auto --subme 7 --trellis 2 --analyse all --8x8dct --me imh --merange 24 --threads auto
avis [info]: 704x400 @ 23.98 fps (4000 frames)
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSSE3
x264 [info]: slice I:48 Avg QP:15.00 size: 25415 PSNR Mean Y:53.75 U:54.82 V:54.87 Avg:54.02 Global:52.68
x264 [info]: slice P:2053 Avg QP:18.00 size: 8055 PSNR Mean Y:48.80 U:49.72 V:50.02 Avg:49.06 Global:48.73
x264 [info]: slice B:1899 Avg QP:19.74 size: 2691 PSNR Mean Y:47.55 U:49.27 V:49.48 Avg:48.00 Global:47.75
x264 [info]: mb I I16..4: 30.5% 41.6% 27.9%
x264 [info]: mb P I16..4: 7.2% 7.3% 2.2% P16..4: 31.1% 9.5% 3.7% 0.4% 0.3% skip:38.2%
x264 [info]: mb B I16..4: 0.1% 0.2% 0.1% B16..8: 14.9% 1.4% 3.4% direct: 4.5% skip:75.3%
x264 [info]: 8x8 transform intra:43.6% inter:42.5%
x264 [info]: direct mvs spatial:98.3% temporal:1.7%
x264 [info]: ref P 68.7% 13.5% 6.7% 3.5% 2.4% 2.1% 1.8% 1.4%
x264 [info]: ref B 77.3% 11.5% 4.0% 2.1% 1.5% 1.5% 1.2% 0.9%
x264 [info]: SSIM Mean Y:0.9947911
x264 [info]: PSNR Mean Y:48.266 U:49.568 V:49.819 Avg:48.618 Global:48.265 kb/s:1096.54
10.47 fps
1096.65 kb/s


--qp 18 --ref 8 --mixed-refs --no-fast-pskip --bframes 5 --b-pyramid --b-rdo --bime --weightb --direct auto --subme 7 --trellis 2 --analyse all --8x8dct --me imh --merange 24 --me-prepass --threads auto
avis [info]: 704x400 @ 23.98 fps (4000 frames)
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSSE3
x264 [info]: slice I:48 Avg QP:15.00 size: 25192 PSNR Mean Y:53.76 U:54.88 V:54.95 Avg:54.05 Global:52.71
x264 [info]: slice P:2036 Avg QP:18.00 size: 7996 PSNR Mean Y:48.82 U:49.69 V:50.00 Avg:49.07 Global:48.74
x264 [info]: slice B:1916 Avg QP:19.74 size: 2728 PSNR Mean Y:47.53 U:49.28 V:49.48 Avg:47.99 Global:47.73
x264 [info]: mb I I16..4: 30.3% 42.1% 27.7%
x264 [info]: mb P I16..4: 7.2% 7.4% 2.2% P16..4: 30.9% 9.5% 3.8% 0.4% 0.3% skip:38.2%
x264 [info]: mb B I16..4: 0.1% 0.3% 0.1% B16..8: 15.1% 1.4% 3.5% direct: 4.5% skip:75.0%
x264 [info]: 8x8 transform intra:43.8% inter:42.4%
x264 [info]: direct mvs spatial:99.6% temporal:0.4%
x264 [info]: ref P 68.5% 13.5% 6.7% 3.4% 2.4% 2.1% 1.8% 1.4%
x264 [info]: ref B 76.9% 11.4% 4.0% 2.2% 1.7% 1.6% 1.2% 1.0%
x264 [info]: SSIM Mean Y:0.9947875
x264 [info]: PSNR Mean Y:48.261 U:49.557 V:49.807 Avg:48.611 Global:48.257 kb/s:1089.30
8.42 fps
1089.42 kb/s


--qp 18 --ref 8 --mixed-refs --no-fast-pskip --bframes 5 --b-pyramid --b-rdo --bime --weightb --direct auto --subme 7 --trellis 2 --analyse all --8x8dct --me imh --merange 24 --fpel-cmp satd --threads auto
avis [info]: 704x400 @ 23.98 fps (4000 frames)
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSSE3
x264 [info]: slice I:48 Avg QP:15.00 size: 25713 PSNR Mean Y:53.71 U:54.66 V:54.64 Avg:53.93 Global:52.64
x264 [info]: slice P:2082 Avg QP:18.00 size: 7958 PSNR Mean Y:48.80 U:49.71 V:50.02 Avg:49.06 Global:48.74
x264 [info]: slice B:1870 Avg QP:19.74 size: 2682 PSNR Mean Y:47.51 U:49.27 V:49.45 Avg:47.97 Global:47.73
x264 [info]: mb I I16..4: 30.5% 41.2% 28.2%
x264 [info]: mb P I16..4: 7.3% 7.1% 2.1% P16..4: 30.5% 9.9% 3.5% 0.5% 0.3% skip:38.8%
x264 [info]: mb B I16..4: 0.1% 0.2% 0.1% B16..8: 14.9% 1.4% 3.4% direct: 4.6% skip:75.3%
x264 [info]: 8x8 transform intra:42.9% inter:44.1%
x264 [info]: direct mvs spatial:99.0% temporal:1.0%
x264 [info]: ref P 69.5% 13.3% 6.4% 3.3% 2.3% 2.0% 1.7% 1.4%
x264 [info]: ref B 77.5% 11.4% 4.0% 2.1% 1.6% 1.4% 1.1% 0.9%
x264 [info]: SSIM Mean Y:0.9947945
x264 [info]: PSNR Mean Y:48.256 U:49.566 V:49.811 Avg:48.607 Global:48.265 kb/s:1094.17
4.72 fps
1094.29 kb/s


--qp 18 --ref 8 --mixed-refs --no-fast-pskip --bframes 5 --b-pyramid --b-rdo --bime --weightb --direct auto --subme 7 --trellis 2 --analyse all --8x8dct --me imh --merange 24 --me-prepass --fpel-cmp satd --threads auto
avis [info]: 704x400 @ 23.98 fps (4000 frames)
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSSE3
x264 [info]: slice I:46 Avg QP:15.00 size: 26108 PSNR Mean Y:53.70 U:54.72 V:54.71 Avg:53.95 Global:52.60
x264 [info]: slice P:2018 Avg QP:18.00 size: 8046 PSNR Mean Y:48.79 U:49.70 V:50.00 Avg:49.05 Global:48.73
x264 [info]: slice B:1936 Avg QP:19.74 size: 2694 PSNR Mean Y:47.55 U:49.29 V:49.50 Avg:48.00 Global:47.76
x264 [info]: mb I I16..4: 30.3% 41.2% 28.5%
x264 [info]: mb P I16..4: 7.6% 7.3% 2.1% P16..4: 30.4% 10.2% 3.6% 0.5% 0.3% skip:37.9%
x264 [info]: mb B I16..4: 0.1% 0.3% 0.1% B16..8: 14.9% 1.5% 3.4% direct: 4.5% skip:75.3%
x264 [info]: 8x8 transform intra:42.8% inter:43.9%
x264 [info]: direct mvs spatial:99.3% temporal:0.7%
x264 [info]: ref P 69.5% 13.2% 6.5% 3.3% 2.3% 2.1% 1.8% 1.4%
x264 [info]: ref B 77.6% 11.1% 3.9% 2.3% 1.6% 1.5% 1.1% 1.0%
x264 [info]: SSIM Mean Y:0.9947976
x264 [info]: PSNR Mean Y:48.246 U:49.560 V:49.812 Avg:48.599 Global:48.260 kb/s:1086.30
3.82 fps
1086.42 kb/s


--qp 18 --ref 8 --mixed-refs --no-fast-pskip --bframes 5 --b-pyramid --b-rdo --bime --weightb --direct auto --subme 7 --trellis 2 --analyse all --8x8dct --me esa --merange 24 --threads auto
avis [info]: 704x400 @ 23.98 fps (4000 frames)
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSSE3
x264 [info]: slice I:48 Avg QP:15.00 size: 25415 PSNR Mean Y:53.75 U:54.82 V:54.87 Avg:54.02 Global:52.68
x264 [info]: slice P:2053 Avg QP:18.00 size: 8053 PSNR Mean Y:48.83 U:49.71 V:50.00 Avg:49.08 Global:48.74
x264 [info]: slice B:1899 Avg QP:19.74 size: 2686 PSNR Mean Y:47.57 U:49.25 V:49.46 Avg:48.01 Global:47.76
x264 [info]: mb I I16..4: 30.5% 41.6% 27.9%
x264 [info]: mb P I16..4: 7.3% 7.3% 2.1% P16..4: 31.1% 9.7% 3.8% 0.5% 0.3% skip:37.9%
x264 [info]: mb B I16..4: 0.1% 0.2% 0.1% B16..8: 14.8% 1.4% 3.4% direct: 4.5% skip:75.4%
x264 [info]: 8x8 transform intra:43.4% inter:41.9%
x264 [info]: direct mvs spatial:99.4% temporal:0.6%
x264 [info]: ref P 69.0% 13.3% 6.6% 3.4% 2.4% 2.1% 1.8% 1.4%
x264 [info]: ref B 77.0% 11.6% 4.1% 2.2% 1.6% 1.5% 1.2% 0.9%
x264 [info]: SSIM Mean Y:0.9948316
x264 [info]: PSNR Mean Y:48.292 U:49.551 V:49.802 Avg:48.631 Global:48.272 kb/s:1095.86
5.04 fps
1095.97 kb/s


--qp 18 --ref 8 --mixed-refs --no-fast-pskip --bframes 5 --b-pyramid --b-rdo --bime --weightb --direct auto --subme 7 --trellis 2 --analyse all --8x8dct --me esa --merange 24 --me-prepass --fpel-cmp satd --threads auto
avis [info]: 704x400 @ 23.98 fps (4000 frames)
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSSE3
mp4 [info]: initial delay 250 (scale 2997)
x264 [info]: slice I:46 Avg QP:15.00 size: 26108 PSNR Mean Y:53.70 U:54.72 V:54.71 Avg:53.95 Global:52.60
x264 [info]: slice P:2018 Avg QP:18.00 size: 8044 PSNR Mean Y:48.85 U:49.68 V:49.98 Avg:49.09 Global:48.75
x264 [info]: slice B:1936 Avg QP:19.74 size: 2688 PSNR Mean Y:47.59 U:49.27 V:49.48 Avg:48.03 Global:47.77
x264 [info]: mb I I16..4: 30.3% 41.2% 28.5%
x264 [info]: mb P I16..4: 7.5% 7.1% 2.0% P16..4: 30.9% 10.4% 3.7% 0.5% 0.3% skip:37.5%
x264 [info]: mb B I16..4: 0.1% 0.2% 0.1% B16..8: 14.9% 1.4% 3.5% direct: 4.5% skip:75.3%
x264 [info]: 8x8 transform intra:42.9% inter:43.1%
x264 [info]: direct mvs spatial:99.6% temporal:0.4%
x264 [info]: ref P 69.8% 13.0% 6.5% 3.3% 2.2% 2.0% 1.8% 1.4%
x264 [info]: ref B 77.6% 11.1% 3.9% 2.3% 1.6% 1.5% 1.1% 1.0%
x264 [info]: SSIM Mean Y:0.9948508
x264 [info]: PSNR Mean Y:48.299 U:49.540 V:49.794 Avg:48.633 Global:48.275 kb/s:1085.60
2.17 fps
1085.72 kb/s


Anything else that I should try out, or any corrections to the settings that I used...?

[buzzqw]

what's looking better ?

BHH

[martino]

Take a look at the SSIM? It's rather impossible by looking at the videos side to side, as one would have guessed. But myself I see --me imh with --me-prepass as a manageable combo (ie don't slow the process down by too much).

--fpel-cmp satd looks like a speed killer (maybe I used it wrongly?), and doesn't seem to provide a marginal improvement. So I don't see myself using this one, maybe only if I have the whole night for an encode to complete (which nowadays I don't since I shut down my PC overnight)...


And yeah; Thank you Dark Shikari for these patches and everyone else who contributed to them! :)

[Terranigma]

--fpel-cmp satd looks like a speed killer (maybe I used it wrongly?)
No, you're using it properly. I've noticed it drops encoding speed significantly as well with a marginal increase in quality. It's for the insane of the insane; those who wants to squeeze out every bit of quality they can (well imho).

[Dark Shikari]

No, you're using it properly. I've noticed it drops encoding speed significantly as well with a marginal increase in quality. It's for the insane of the insane; those who wants to squeeze out every bit of quality they can (well imho).Yup, its less effective on a per-quality basis than any other option, I think.

It also seems to be more effective on live-action footage than on anime.

With the new multithreaded optimized ESA (thanks aku!) it could be very good; my preliminary testing shows that --me esa --fpel-cmp satd may actually be faster than --me imh --me-prepass --fpel-cmp satd.

Another interesting thing is that --me imh --me-prepass gives results almost equivalent to that of --me esa in all cases I've done so far :)

[akupenguin]

Elephants dream 720p (all of it, not just your wire scene)
looks like SATD ESA dominates all the other SATD options.

edit: graph removed, see later post for update

[Dark Shikari]

Wow, that's interesting--with the optimizations made to it, SATD ESA makes all the other SATD options completely unnecessary.

And its interesting how --me-prepass --me imh wipes the floor with --me esa, for SAD.

Obviously it must have taken an ungodly amount of encoding to make that, but I wonder how much --me-prepass helps --me esa?

[akupenguin]

Not so ungodly. Note the 720p SATD ESA merange=32 ran at 8fps, as compared to your 0.05 fps. 8core Xeon ftw.

[Dark Shikari]

Not so ungodly. Note the 720p SATD ESA merange=32 ran at 8fps, as compared to your 0.05 fps. 8core Xeon ftw.:scared:

The 0.05 FPS was the completely unoptimized version too, using a combination of SEA SAD and thresholded SEA SATD on that, and then adding in your tweak to allow multithreaded ESA... suddenly ESA actual became somewhat practical. :)

[Dark Shikari]

Also, in your image, are you measuring quality/bitrate or just bitrate? I assume its quality/bitrate because Prepass in my experience raises bitrate to gain quality, but its labelled as just bitrate, so I'm not exactly sure.

[akupenguin]

quality/bitrate. Though most of the change was in bitrate, none of the samples differed by more than 1% quality.
Running ESA prepass now, estimated 6 hours.

[akupenguin]

http://akuvian.org/images/ed720_me_cmp.png

[Dark Shikari]

I assume that's a typo, and the top one is SATD ESA prepass ;)

But interesting results, though not surprising--very low MERanges will give worse results with Prepass, because Prepass may sometimes move the exhaustive search radius away from the ideal value.

[akupenguin]

Out of all of these data points, prepass never reduces quality. But prepass is slower than incrementing merange, so it's only useful after you hit diminishing returns on merange.

[fields_g]

on the previous graph, I noticed ESA had 9 points tested MERange values tested, while others had 8. What are the meranges that were tested for these?