Current Patches, Where to get them, How they affect speed/output

[DarkZell666]

@komisar & x264 devs : May I dare ask why all those patches aren't in the git ? :o They must have a valid reason for existing don't they ?

[kemuri-_9]

@komisar & x264 devs : May I dare ask why all those patches aren't in the git ? :o They must have a valid reason for existing don't they ?

many of them are features that aren't cared for by the devs or kludge fixes which are also not cared for.

[Trahald]

Hrd patch 12. VFR (pulldown) is considered in the actual buffer size tracker (not planning.) previously just the average rate was used for planning and actual. Average will still be used for planning.
HRD Type II bits (AUD, Sei) are considered in the actual buffer size. Stock x264 has HRD type I compliance which only factors slice data bits in buffer size.

[G_M_C]

Hrd patch 12. VFR (pulldown) is considered in the actual buffer size tracker (not planning.) previously just the average rate was used for planning and actual. Average will still be used for planning.
HRD Type II bits (AUD, Sei) are considered in the actual buffer size. Stock x264 has HRD type I compliance which only factors slice data bits in buffer size.

:thanks:

very much so !

[shon3i]

Thanks Trahald, finally, can this patch finaly included into git?

[Trahald]

Its almost to the point that I'd like it in there (assuming 12 does well when used widely), but not yet. Although I think I'm done with any real changes on it. It just mostly needs code clean up (making sure label conventions are consistent with x264s, etc). Then Its up to the powers that be. Although IIRC, the code end of it wasnt the only objection re: its only needed for bluray.

[shon3i]

its only needed for bluray. This is actually the reason why i ask.

[kemuri-_9]

This is actually the reason why i ask.

does the blu-ray standard not also mandatorily require 4 slices to be used?
with x264 not having used the sliced threading model since ? this is another hit to BD compatibility.

[LoRd_MuldeR]

does the blu-ray standard not also mandatorily require 4 slices to be used?
with x264 not having used the sliced threading model since ? this is another hit to BD compatibility.

If I remember the discussion correctly, then it wasn't 100% sure whether this is more a recommendation or a must.

[Trahald]

4 slice minimum is mandatory . they are to be relatively equal in size.

The additions that the HRD patch makes are the ones that most authoring applications enforce. But yes, a stream must be multi-sliced to truly be compliant.

[shon3i]

I am aware of that, but given that no player has not made a problem. I think we not see slices encoding in x264 that soon :) but will be great to finally make x264 full blu-ray compilant.

[G_M_C]

I am aware of that, but given that no player has not made a problem. I think we not see slices encoding in x264 that soon :) but will be great to finally make x264 full blu-ray compilant.

Yes, when the hrd patch becomes committed, then the "lack of slices" is the last major step for x264 to be able to make fully BD compliant streams.

[skystrife]

x264 r1153 x64 (unpatched) (http://skystrife.com/x264/revision1153/x264.exe)
gcc 4.4.0 (release) fprofiled build.
-------------------------

x264.1153M.lookahead.02.x86.exe (http://skystrife.com/x264/x264.1153M.lookahead.02.x86.exe) / x264.1153M.lookahead.x64.exe (http://skystrife.com/x264/x264.1153M.lookahead.x64.exe)
gcc 4.4.0 (release) fprofiled builds (x86 uses -march=pentium2).

Patches used:

x264-r1134-threaded-slicetype-v14.diff (http://skystrife.com/x264/x264-r1134-threaded-slicetype-v14.diff)
x264_threaded_slicetype_windows_fix.diff (http://skystrife.com/x264/x264_threaded_slicetype_windows_fix.diff)
x264_hrd_pulldown.12_interlace.diff
x264_win_zone_parse_fix_05.diff

Changes from previous releases:

x86 build no longer uses gcc 3.4.5. Reasoning: the threaded slicetype patch does not compile cleanly on windows using the 3.4.x series of gcc, but does with 4.x+.

EDIT: Adding a build without the threaded slicetype patch in a moment, for anyone having issues with this one. (I've had no problems with the windows fix, but that's just me.)

EDIT2: x86 lookeahead build fixed, the pthreads library is now built in. Apologies for the trouble.

[techouse]

x264_x64_r1153_unpatched (http://techouse.project357.com/builds/revision1153/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1153/x264.md5)
GCC 4.3.4 20090408 (prerelease) (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

x264_x86_r1153_techouse (http://techouse.project357.com/builds/x264_x86_r1153_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1153_techouse.txt)
GCC 4.3.3, fprofiled, -march=core2

x264_x64_r1153_techouse (http://techouse.project357.com/builds/x264_x64_r1153_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1153_techouse.txt)
GCC 4.3.4 20090408 (prerelease) (x64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pulldown.12_interlace.diff
x264_win_zone_parse_fix_05.diff

[burfadel]

X264 r1153 + Autovaq?

Thanks! :)

Oh techouse, how come using 4.3.3/4.3.4 (prerelease) if 4.4.0 is out?
Maybe an extra build with Autovaq patch? ;) Just seems to be a very good thing thats all! admitedly I can use a lower CRF, still have smaller files and have better quality with it! hence why I suggested optimising the distribution of bits to keep the CRF's closer, but its good nonetheless.

Oh, and would the builds on x264.nl benefit from gcc 4.4.0 over 3.4.6?

[skystrife]

x264.1153M.x86.exe (http://skystrife.com/x264/x264.1153M.x86.exe) / x264.1153M.x64.exe (http://skystrife.com/x264/x264.1153M.x64.exe)
gcc 4.4.0 (release) fprofiled builds (x86 uses -march=pentium2).

Patches used:

x264_hrd_pulldown.12_interlace.diff
x264_win_zone_parse_fix_05.diff

Use this if the slicetype patch is giving you issues. I'll also put up an AutoVAQ build here in a bit, as well as a x64 build without the slicetype patch.

EDIT: Oh ffs, I accidentally deleted it... It'll be up in a bit, I swear. -_-

EDIT2: Ok, finally up. Never make clean until after you have your binary elsewhere. -_-;

EDIT3: x64 binary up.

[Underground78]

EDIT: Oh ffs, I accidentally deleted it... It'll be up in a bit, I swear. -_-

The error page is really good ! :p

[skystrife]

The error page is really good ! :p

lol, thanks.

-------------------------

x264.1153M.AutoVAQ.x86.exe (http://skystrife.com/x264/x264.1153M.AutoVAQ.x86.exe) / x264.1153M.AutoVAQ.x64.exe (http://skystrife.com/x264/x264.1153M.AutoVAQ.x64.exe)
gcc 4.4.0 (release) fprofiled builds (x86 uses -march=pentium2).

Patches used:

x264_hrd_pulldown.12_interlace.diff
x264_win_zone_parse_fix_05.diff
x264_AutoVAQ.02.diff (see AutoVAQ thread)

Also note the new x86 build including the lookahead patch (this contains a built-in pthread library, unlike the previous one, my mistake).

[woah!]

lol, thanks.

-------------------------

x264.1153M.AutoVAQ.x86.exe (http://skystrife.com/x264/x264.1153M.AutoVAQ.x86.exe) / x264.1153M.AutoVAQ.x64.exe (http://skystrife.com/x264/x264.1153M.AutoVAQ.x64.exe)
gcc 4.4.0 (release) fprofiled builds (x86 uses -march=pentium2).

Patches used:

x264_hrd_pulldown.12_interlace.diff
x264_win_zone_parse_fix_05.diff
x264_AutoVAQ.02.diff (see AutoVAQ thread)

Also note the new x86 build including the lookahead patch (this contains a built-in pthread library, unlike the previous one, my mistake).

anyone having issues running the 2nd pass with your x86 build? i can complete crf mode and the 1st pass using it, but it just sits hanging at the cpu capabilities info ?

using a prior build 1148 works correctly on exact same script.


update; hmm ok techhouse build 1153 does the same? this is the last one i seem to have no issues with http://forum.doom9.org/showpost.php?p=1283584&postcount=1847

also your 1148 build works ok aswell. what has changed since 1148?

[desta]

anyone having issues running the 2nd pass with your x86 build? i can complete crf mode and the 1st pass using it, but it just sits hanging at the cpu capabilities info ?

using a prior build 1148 works correctly on exact same script.


update; hmm ok techhouse build 1153 does the same? this is the last one i seem to have no issues with http://forum.doom9.org/showpost.php?p=1283584&postcount=1847

also your 1148 build works ok aswell. what has changed since 1148?

Have a look here (http://forum.doom9.org/showthread.php?p=1288666#post1288666).

[kemuri-_9]

to better assist with nailing down problems, please provide more information on the source you're encoding and the settings on each pass you're using.

i've been trying to test the recent patches but haven't yet been able to get them to crash/fail as reported...

[woah!]

ahh good stuff, not a issue with my setup then :)

[woah!]

to better assist with nailing down problems, please provide more information on the source you're encoding and the settings on each pass you're using.

i've been trying to test the recent patches but haven't yet been able to get them to crash/fail as reported...

here's my setup:

-p 1 -B 9046 --stats "X:\264.stats" --aq-strength 1.0 -f -2:-1 --aq-mode 2 --b-adapt 1 --psy-rd "0.0:0.0" -t 1 --level 4.1 --keyint 24 --min-keyint 1 -ref 3 --mixed-refs --bframes 3 --weightb --direct auto --subme 8 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 30000 --vbv-maxrate 38000 --qcomp 0.5 --me dia --threads auto --progress --no-psnr --mvrange 511 --aud --nal-hrd --sar 1:1 -o NUL "Y:\BLURAY.avs"
avis [info]: 1920x1080 @ 23.98 fps (1001 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cache64
x264 [info]: profile High, level 4.1
x264 [info]: slice I:58 Avg QP:18.38 size:117026
x264 [info]: slice P:411 Avg QP:19.23 size: 76409
x264 [info]: slice B:532 Avg QP:20.56 size: 19960
x264 [info]: consecutive B-frames: 13.7% 26.1% 21.6% 38.6%
x264 [info]: mb I I16..4: 35.9% 60.8% 3.3%
x264 [info]: mb P I16..4: 10.4% 22.2% 1.2% P16..4: 25.9% 6.9% 3.9% 0.0% 0
.0% skip:29.5%
x264 [info]: mb B I16..4: 0.7% 1.2% 0.2% B16..8: 26.2% 0.9% 1.0% direct:
5.9% skip:64.0% L0:25.3% L1:36.9% BI:37.8%
x264 [info]: final ratefactor: 17.90
x264 [info]: 8x8 transform intra:64.0% inter:59.2%
x264 [info]: direct mvs spatial:99.1% temporal:0.9%
x264 [info]: coded y,uvDC,uvAC intra:77.4% 78.2% 54.8% inter:21.7% 22.7% 1.3%
x264 [info]: ref P L0 86.9% 8.1% 5.0%
x264 [info]: ref B L0 97.0% 3.0%
x264 [info]: SSIM Mean Y:0.9831512
x264 [info]: kb/s:9352.8

encoded 1001 frames, 10.42 fps, 9353.56 kb/s

-p 2 -B 9046 --stats "X:\264.stats" --aq-strength 1.0 -f -2:-1 --aq-mode 2 --b-adapt 1 --psy-rd "0.0:0.0" -t 1 --level 4.1 --keyint 24 --min-keyint 1 --ref 3 --mixed-refs --bframes 3 --weightb --direct auto --subme 8 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 30000 --vbv-maxrate 38000 --qcomp 0.5 --me umh --threads auto -progress --no-psnr --mvrange 511 --aud --nal-hrd --sar 1:1 -o "Y:\STARTREK_VI.264" "Y:\BLURAY.avs"
avis [info]: 1920x1080 @ 23.98 fps (1001 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cach
e64

Y:\>pause
Press any key to continue . . .

avs script:

DGSource("Y:\!bluray_encoding\STARTREK_VI.dga")


thats it heh...

on the second pass the encode stops at cache64, weird as 1st pass is ok.

[kemuri-_9]

on the second pass the encode stops at cache64, weird as 1st pass is ok.

Thank you, I've been able to confirm the crash is resulting in the change from the v11 to v12 of the hrd/interlace patch.

Edit:
so any build with the x264_hrd_pulldown.12_interlace.diff will crash if --vbv-bufsize is given on the command line for the 2nd pass.

[woah!]

just to let you know, crf mode works just fine so it is just a 2 pass bug.

[Trahald]

I havent been able to duplicate it. I am using 1153 with just hrd 12 patch. 2 pass works fine. I am using the old gcc(3.4.5) and i dont have gpac on. I have vbv-bufsize in my cli. does it crash right away or take some time?

[kemuri-_9]

I havent been able to duplicate it. I am using 1153 with just hrd 12 patch. 2 pass works fine. I am using the old gcc(3.4.5) and i dont have gpac on. I have vbv-bufsize in my cli. does it crash right away or take some time?

the crash happens immediately.
I was working from woah!'s command line and it stopped crashing once i removed --vbv-buffsize...

i can even knock off params until i get to the following command line

-p 2 -B 9046 --vbv-bufsize 30000 -o OUTPUT INPUT

and it still crashes.

this is happening in both gcc 3.4.5 and 4.4.0

here's a bt of the error from my end.

Program received signal SIGSEGV, Segmentation fault.

bt
#0 0x77bd1a02 in msvcrt!fclose () from C:\WINDOWS\syswow64\msvcrt.dll
#1 0x003f7410 in ?? ()
#2 0x025d6fe8 in ?? ()
#3 0x0232da40 in ?? ()
#4 0xffffffff in ?? ()
#5 0x0022f3a0 in ?? ()
#6 0x417fca05 in ?? ()
#7 0x0022ffe0 in ?? ()
#8 0x77bc6c74 in msvcrt!_except_handler2 ()
from C:\WINDOWS\syswow64\msvcrt.dll
#9 0x004227bb in vbv_pass2 (h=<incomplete type>)
at encoder/ratecontrol.c:1799
Backtrace stopped: previous frame inner to this frame (corrupt stack?)


here's a bt from a linux machine which may be more useful:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210382656 (LWP 15469)]
0xb7e05dcd in fclose () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0 0xb7e05dcd in fclose () from /lib/tls/i686/cmov/libc.so.6
#1 0x08097cef in init_pass2 (h=0x80d83b0) at encoder/ratecontrol.c:1799
#2 0x0809941d in x264_ratecontrol_new (h=0x80d83b0) at encoder/ratecontrol.c:575
#3 0x0805443c in x264_encoder_open (param=0xbfb34588) at encoder/encoder.c:811
#4 0x0804aa0a in main (argc=10, argv=0xbfb34864) at x264.c:816

[Trahald]

Ahh. it was some debug code i added and didnt completely delete. Sorry. Still not sure why its not crashing here (it should). here is 13. Thanks aku and kemuri_9 for helping fix it.

[skystrife]

x264.1153M.02.x86.exe (http://skystrife.com/x264/x264.1153M.02.x86.exe) / x264.1153M.02.x64.exe (http://skystrife.com/x264/x264.1153M.02.x64.exe)
gcc 4.4.0 (release) fprofiled builds (x86 uses -march=pentium2).

Patches used:

x264_hrd_pulldown.13_interlace.diff
x264_win_zone_parse_fix_05.diff

-------------------------

x264.1153M.AutoVAQ.02.x86.exe (http://skystrife.com/x264/x264.1153M.AutoVAQ.02.x86.exe) / x264.1153M.AutoVAQ.02.x64.exe (http://skystrife.com/x264/x264.1153M.AutoVAQ.02.x64.exe)
gcc 4.4.0 (release) fprofiled builds (x86 uses -march=pentium2).

Patches used:

x264_hrd_pulldown.13_interlace.diff
x264_win_zone_parse_fix_05.diff
x264_AutoVAQ.02.diff

[JEEB]

x264 r1158 32bit
download (http://jeeb.fiveforty.jp/x264/1158/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1158/relnotes.txt)

built on May 25 2009, gcc: 4.3.3
fprofiled, -march=i686 (now default in x264)


x264 r1158 64bit
download (http://jeeb.fiveforty.jp/x264/1158_x64/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1158_x64/relnotes.txt)

built on May 25 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, -march=core2


Both patched with:

x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.13_interlace.diff

[skystrife]

x264.1158M.x86.exe (http://skystrife.com/x264/x264.1158M.x86.exe) / x264.1158M.x64.exe (http://skystrife.com/x264/x264.1158M.x64.exe)
gcc 4.4.0 (release) fprofiled builds (x86 uses -march=pentium2).

Patches used:

x264_hrd_pulldown.13_interlace.diff
x264_win_zone_parse_fix_05.diff

-------------------------

x264.1158M.AutoVAQ.x86.exe (http://skystrife.com/x264/x264.1158M.AutoVAQ.x86.exe) / x264.1158M.AutoVAQ.x64.exe (http://skystrife.com/x264/x264.1158M.AutoVAQ.x64.exe)
gcc 4.4.0 (release) fprofiled builds (x86 uses -march=pentium2).

Patches used:

x264_hrd_pulldown.13_interlace.diff
x264_win_zone_parse_fix_05.diff
x264_AutoVAQ.02.diff

[XhmikosR]

Hi, skystrife. I downloaded your x264.1158M.x86.exe, and in version it shows:

x264 0.67.1153M 7b6ce6a
built on May 24 2009, gcc: 4.4.0

[Audionut]

Yup, same for VAQ.x86.

[JEEB]

Patches used:

x264_hrd_pulldown.12_interlace.diff
x264_win_zone_parse_fix_05.diff
I really hope that this is just a mistake caused by copypasta since the revision 12 seems to have bugs (which is why there's revision 13 of it out already here (http://forum.doom9.org/showpost.php?p=1288917&postcount=1878)).

Just had to mention that (since some people actually use the nal-hrd stuff, and usually with vbv).

[techouse]

x264_x64_r1159_unpatched (http://techouse.project357.com/builds/revision1159/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1159/x264.md5)
GCC 4.4.0 20090524 (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

x264_x86_r1159_techouse (http://techouse.project357.com/builds/x264_x86_r1159_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1159_techouse.txt)
GCC 4.4.0 20090524 (x86.core2.Komisar), fprofiled, -march=core2

x264_x64_r1159_techouse (http://techouse.project357.com/builds/x264_x64_r1159_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1159_techouse.txt)
GCC 4.4.0 20090524 (x64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pulldown.13_interlace.diff
x264_win_zone_parse_fix_05.diff

[komisar]

Someone confirm the change of the progress indicator?
I see "[-1.$%] 80/144475 frames, 0.00 fps, 169.94 kb/s, eta 2:17:15" in my, techouse and skystrife builds.

Perhaps another bug in gcc 4.4.X profiling...

[kemuri-_9]

Someone confirm the change of the progress indicator?
I see "[-1.$%] 80/144475 frames, 0.00 fps, 169.94 kb/s, eta 2:17:15" in my, techouse and skystrife builds.

Perhaps another bug in gcc 4.4.X profiling...

there's not been any code changes to the progress indication in the last few revisions...
i haven't seen any problems with my 4.4.0 builds
nor have I been able to replicate it now with techouse's or skystrife's

and that does particularly look like an error caused by a floating point exception...

[komisar]

kemuri-_9
I test only 64bit builds. fps and % always as in my previous post.

in some situation x264 crash (gcc 4.4.0 profiled and not-profiled builds) and i seex264 [info]: profile Main, level 3.0
[-47132383076129555000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000.0%] 10/185605 frames, 26.67 fps, 133.86 kb/s, eta 1:55:59
compiled with gcc 4.3.4 work fine.

[techouse]

Hmm, my patched and unpatched 64bit GCC 4.4.0 builds (r1159) work fine for me...

x264 [info]: 1280x534 @ 23.98 fps
x264 [warning]: width or height not divisible by 16 (1280x534), compression will suffer.
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 4.1
my_movie.avs: 1280x534, 24000/1001 fps, 238873 frames
[0.2%] 590/238873 frames, 2.84 fps, 4986.28 kb/s, eta 23:20:08
I'll keep the thing running and report back any crashes or anything unusual...

EDIT: Have been running the thing for a day now without any crashes or anything.

[juGGaKNot]

1160 autovaq please...

[techouse]

x264_x64_r1160_unpatched (http://techouse.project357.com/builds/revision1160/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1160/x264.md5)
GCC 4.4.0 20090524 (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

x264_x86_r1160_techouse (http://techouse.project357.com/builds/x264_x86_r1160_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1160_techouse.txt)
GCC 4.4.0 20090524 (x86.core2.Komisar), fprofiled, -march=core2

x264_x64_r1160_techouse (http://techouse.project357.com/builds/x264_x64_r1160_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1160_techouse.txt)
GCC 4.4.0 20090524 (x64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pulldown.13_interlace.diff
x264_win_zone_parse_fix_05.diff

________________________________________________________________________________

x264_x86_r1160_AutoVAQ.0.2_techouse (http://techouse.project357.com/builds/x264_x86_r1160_AutoVAQ.0.2_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1160_AutoVAQ.0.2_techouse.txt)
GCC 4.4.0 20090524 (x86.core2.Komisar), fprofiled, -march=core2

x264_x64_r1160_AutoVAQ.0.2_techouse (http://techouse.project357.com/builds/x264_x64_r1160_AutoVAQ.0.2_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1160_AutoVAQ.0.2_techouse.txt)
GCC 4.4.0 20090524 (x64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_AutoVAQ.02.diff
x264_hrd_pulldown.13_interlace.diff
x264_win_zone_parse_fix_05.diff

[JEEB]

x264 r1162 32bit
download (http://jeeb.fiveforty.jp/x264/1162/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1162/relnotes.txt)

built on May 27 2009, gcc: 4.3.3
fprofiled, -march=i686


x264 r1162 64bit
download (http://jeeb.fiveforty.jp/x264/1162_x64/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1162_x64/relnotes.txt)

built on May 27 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, -march=core2


Both patched with:

x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.13_interlace.diff


x264 r1162 AutoVAQ patched:

32bit (http://jeeb.fiveforty.jp/x264/1162avaq/x264.exe)
64bit (http://jeeb.fiveforty.jp/x264/1162avaq_x64/x264.exe)

(Built otherwise with the same patches, settings and compilers. x264_AutoVAQ.02.diff version of the AutoVAQ patch used.)

[techouse]

x264_x64_r1163_unpatched (http://techouse.project357.com/builds/revision1163/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1163/x264.md5)
GCC 4.4.0 20090524 (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

x264_x86_r1163_techouse (http://techouse.project357.com/builds/x264_x86_r1163_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1163_techouse.txt)
GCC 4.4.0 20090524 (x86.core2.Komisar), fprofiled, -march=core2

x264_x64_r1163_techouse (http://techouse.project357.com/builds/x264_x64_r1163_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1163_techouse.txt)
GCC 4.4.0 20090524 (x64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_hrd_pulldown.13_interlace.diff
x264_win_zone_parse_fix_05.diff

________________________________________________________________________________

x264_x86_r1163_AutoVAQ.0.2_techouse (http://techouse.project357.com/builds/x264_x86_r1163_AutoVAQ.0.2_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x86_r1163_AutoVAQ.0.2_techouse.txt)
GCC 4.4.0 20090524 (x86.core2.Komisar), fprofiled, -march=core2

x264_x64_r1163_AutoVAQ.0.2_techouse (http://techouse.project357.com/builds/x264_x64_r1163_AutoVAQ.0.2_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1163_AutoVAQ.0.2_techouse.txt)
GCC 4.4.0 20090524 (x64.core2.Komisar), fprofiled, -march=core2

Patches used:

x264_AutoVAQ.02.diff
x264_hrd_pulldown.13_interlace.diff
x264_win_zone_parse_fix_05.diff

[Fr4nz]

I point out a new ICC compiled version of x264, made by IMK for Windows and MacOS systems:
http://imk.cx/pc/x264/x264-r1163M-imk-win.7z
http://imk.cx/pc/x264/x264-r1163M-imk-osx.7z

These versions are very very performant with Intel Core Duo/Quads (maybe also i7?), so I recommend them if you have these CPUs.

[laserfan]

I point out a new ICC compiled version of x264...very very performant with Intel Core Duo/Quads (maybe also i7Sorry but in looking at the build info I see something and have to ask: what means "with MP4 output" i.e. what does that build do that's different?

[LoRd_MuldeR]

Sorry but in looking at the build info I see something and have to ask: what means "with MP4 output" i.e. what does that build do that's different?

You can build x264 with or without GPAC. Without GPAC it won't be able to put out MP4 files. Only MKV files.

That applies to all builds of x264, no matter what compiler is used. Most builds of x264 CLI have GPAC (MP4 output) enabled.

BTW: I highly doubt that his ICC builds are that much faster compared to the usual GCC builds. That's because all the performance-critical functions in x264 are hand-optimized ASM code anyway. Compiler optimizations only effect the plain C code. So maybe the ICC builds are a bit faster than GCC indeed, but not that dramatically faster as one could assume from his post...

[roozhou]

BTW: I highly doubt that his ICC builds are that much faster compared to the usual GCC builds. That's because all the performance-critical functions in x264 are hand-optimized ASM code anyway. Compiler optimizations only effect the plain C code. So maybe the ICC builds are a bit faster than GCC indeed, but not that dramatically faster as one could assume from his post...
Does ICC has something similar to GCC's fprofile and MSVC's PGO? According to my test, profiling does increase performance by ~3% for GCC build and ~5% for MSVC build.

[Fr4nz]

BTW: I highly doubt that his ICC builds are that much faster compared to the usual GCC builds. That's because all the performance-critical functions in x264 are hand-optimized ASM code anyway. Compiler optimizations only effect the plain C code. So maybe the ICC builds are a bit faster than GCC indeed, but not that dramatically faster as one could assume from his post...

Yes, the speedup is not big/enormous but there is indeed a ~4-5% gain.

Example with latest 1163 release encoding SD content (720x480) in MeGUI with "balanced SD" preset at 1000kbps (my system is a E6750 @3,3ghz with 2GB of RAM and WinXP SP3):

- ICC x264 v1163: 141,57 fps 1st pass; 56,42 fps 2nd pass
- Latest megui x264 version (v1162 Jeeb patched build): 136,29 fps 1st pass; 54,83 fps 2nd pass

[roozhou]

Yes, the speedup is not big/enormous but there is indeed a ~4-5% gain.

Example with latest 1163 release encoding SD content (720x480) in MeGUI with "balanced SD" preset at 1000kbps (my system is a E6750 @3,3ghz with 2GB of RAM and WinXP SP3):

- ICC x264 v1163: 141,57 fps 1st pass; 56,42 fps 2nd pass
- Latest megui x264 version (v1162 Jeeb patched build): 136,29 fps 1st pass; 54,83 fps 2nd pass

You are comparing 1163 and 1162, and they are using different patches.

[wyti]

it's the same, the only difference between those 2 builds is the configure file.