Log in

View Full Version : Current Patches, Where to get them, How they affect speed/output


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 [41] 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69

Trahald
16th July 2009, 17:43
If we're free to post ideas here, I tried working on it but don't really have the experience to get it done. An option --encoder-fps would tune your options every so many frames to try to match fps to --encoder-fps value. Bframes would be lowered or raised, refs decreased or increased, etc. It would be very useful if performing faster than a certain speed is crucial. The only issues I'd foresee is that certain options (like bframes) probably can't be changed very easily in the middle of encoding.

bframes (the amount used in a GOP not the parameter per se) can change naturally based on the material. Changing that as a parameter mid-stream (from 3 to 0 for example) is trivial. other parameters require changing the sps/pps which is more significant but doable. Some encoders do this but usually based on changes in a section of the source, not to meet a speed requirement.
It would be interesting for the sake of better quality @ same bitrate. Doing it for encoding fps sake doesnt seem a good enough reason IMHO.

Dark Shikari
16th July 2009, 18:53
If we're free to post ideas here, I tried working on it but don't really have the experience to get it done. An option --encoder-fps would tune your options every so many frames to try to match fps to --encoder-fps value. Bframes would be lowered or raised, refs decreased or increased, etc. It would be very useful if performing faster than a certain speed is crucial. The only issues I'd foresee is that certain options (like bframes) probably can't be changed very easily in the middle of encoding.This patch already exists, and it's called speedcontrol. If you need it, contact Michael Kazmier at firstinitial lastname [AT] availmedia [DOT] com.

JEEB
17th July 2009, 10:09
x264 r1183 32bit
download (http://jeeb.fiveforty.jp/x264/1183/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1183/relnotes.txt)

built on Jul 17 2009, gcc: 4.3.3
fprofiled, -march=i686


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

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


patched with:

x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.13_interlace_modified.diff (http://jeeb.fiveforty.jp/x264/patches/x264_hrd_pulldown.13_interlace_modified.diff)
x264_AutoVAQ.03.diff

imk
18th July 2009, 03:12
Windows:
x264-r1183M-imk-win.7z (http://imk.cx/pc/x264/x264-r1183M-imk-win.7z)
win_build_info.txt (http://imk.cx/pc/x264/win_build_info.txt)

OS X (x86 + x86-64 Universal Binary):
x264-r1183M-imk-osx.7z (http://imk.cx/pc/x264/x264-r1183M-imk-osx.7z)



I'm not going to include the AutoVAQ patch just yet. I might include the threaded slicetype patch if enough people use it or want it.

techouse
20th July 2009, 23:27
x264_x64_r1184_unpatched (http://techouse.project357.com/builds/revision1184/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1184/x264.md5)
GCC 4.4.0 20090524 (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

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

x264_x64_r1184_techouse (http://techouse.project357.com/builds/x264_x64_r1184_techouse.7z) | INFO (http://techouse.project357.com/nfo/x264_x64_r1184_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

imk
21st July 2009, 08:40
x264-r1184M-imk-win.7z (http://imk.cx/pc/x264/x264-r1184M-imk-win.7z)
win_build_info.txt (http://imk.cx/pc/x264/win_build_info.txt)

JEEB
21st July 2009, 13:30
x264 r1184 32bit
download (http://jeeb.fiveforty.jp/x264/1184/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1184/relnotes.txt)

built on Jul 21 2009, gcc: 4.3.4 20090220 (prerelease) (x32.generic.Komisar)
fprofiled, -march=i686


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

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


patched with:

x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.14_interlace.diff


One less patch to apply, the AutoVAQ is in.

EDIT:
Now used the 64bit VM Komisar build system to build both, the problems with the 32bit build should be over. I personally haven't edited my build environment in quite some time so I have no idea what caused the problems from r1179 onwards.

Kurtnoise
21st July 2009, 14:34
Jeeb: did you change something in the code except patches ? coz I tested this command : x264.exe -h w/ your build and it crashes...:confused: it works fine with --help or --longhelp though (OS: win 7 32bits). Note that I've no crashes w/ my own build (gcc 4.4.0) using the same command.

Does anyone confirm or not ?

DarkZell666
21st July 2009, 14:39
Jeeb: did you change something in the code except patches ? coz I tested this command : x264.exe -h w/ your build and it crashes...:confused: it works fine with --help or --longhelp though (OS: win 7 32bits). Note that I've no crashes w/ my own build (gcc 4.4.0) using the same command.

Does anyone confirm or not ?

Confirmed here on XP 32-bits.
x264 -h doesn't show anything, it just quits without any error/warning.
Edit : Imk's build is ok for me.

LoRd_MuldeR
21st July 2009, 14:49
x264 -h doesn't show anything, it just quits without any error/warning.

In fact it seems all the "short" switches will cause x264 to exit immediately ("-h", "-w", "-B", etc). The x64 build is not effected though...

JEEB
21st July 2009, 15:09
Very weird. My building script consists of rm -rf'ing all of the current build folders -> updating the git repo (using one folder that never gets used for building) -> copying to the needed folders -> configuration and building. No additional patches were applied and the 32bit version gets even a standard ./configure because x264 by default optimizes for i686 IIRC.

I remember using the short commands myself earlier, so I will definitely have to take a look at it as I get home. :scared: And patching logs seemed to be all right.

Also, the 64bit build being not affected makes me think even more...

Too bad I don't have the msys environment on my hands via remote desktop :/

Possible culprits:
- my toolchain (hasn't been updated in a while though, so if it actually worked on the older builds...)
- that modified HRD patch (that has been there for some time as well; hurf, I was worried something might happen, because it was my first case, but let's see as the change was quite small...)
- getting updated code from the git repo went not-so-well?
- something else?

Will test some older binaries via wine on my laptop now.

EDIT:


r1184-83-81-79 32bit:
err:seh:setup_exception_record stack overflow 820 bytes in thread 0009 eip b7d269be esp 00520ffc stack 0x520000-0x521000-0x720000
r1173 32bit:
Works


Hurf, I think you can guess the reason and I will go cry myself to sleep with my patch that I made by applying it manually to the codebase and then doing diff magic. Will switch to the 1178 version by komisar and go hang myself ^^;

Although why the hell does it work on 64bit D:

EDIT2:

wtf, it even happens without any patches, I guess my build environment got changed somehow o_O I haven't touched it for months. Anyways, fun stuff.

EDIT3: Re-built the build with Trahald's v14 hrd pulldown patch on Komisar's msys/mingw - problems fixed, which is the main part - now to know why on Earth it failed on my 32bit building environment...

Trahald
21st July 2009, 15:40
No really big changes. Just code clean up. The 3 length values in the code were at maxes, which works but wastes bits, were lowered to reflect options given. I ran a few encodes at it and the calcs make sense to me, but be ready to revert if there is an issue.

Tarutaru
23rd July 2009, 16:01
x264 0.68.1185M 2956905 built on Jul 23 2009, gcc: 4.4.0 (http://www.mediafire.com/?qdm2yzi2tyt)

* patch -p1 < /local/build/x264/patch/x264_hrd_pulldown.14_interlace.diff
* patch -p1 < /local/build/x264/patch/x264_win_zone_parse_fix_05.diff
* fprofiled, -msse4.2, -march=native(core i7)
* built with pthread, gpac

kemuri-_9
24th July 2009, 17:10
since this thread is also used for discussion and usage of patched builds, tossing the following out...

in addition to the release of gcc 4.4.1 as of a couple days ago, the mingw team has also revealed an official 4.4.0 release (which unlike 4.3.0 isn't stated as alpha/testing).
so those still using 3.4.5 should definitely upgrade...

LoRd_MuldeR
24th July 2009, 17:21
Is there a MinGW 4.4.1 binary yet? It seems TDM's builds have not been updated until now...

kemuri-_9
24th July 2009, 17:32
Is there a MinGW 4.4.1 binary yet? It seems TDM's builds have not been updated until now...

you always have the option to compile your own from source (like what i do)

LoRd_MuldeR
24th July 2009, 17:35
you always have the option to compile your own from source (like what i do)

Too much trouble :D

And I prefer using some "semi official" MinGW/GCC build, because it's more tested by the community.

Selur
24th July 2009, 17:48
I agree, tdm's builds are nice&handy :)
(btw. is there something similiar when aiming for 64bit builds?)

LoRd_MuldeR
24th July 2009, 17:55
People seem to use Komisar's MinGW x64 builds:
http://komisar.gin.by/mingw/index.html

komisar
24th July 2009, 18:09
My last stable build of gcc -- 4.3.4 20090620.
After 20090620 my trying to build correct gcc and x264 fail.
gcc 4.5.0 (svn) totally unstable (imho).
4.4.1 i can try to build after weekend.

kemuri-_9
24th July 2009, 18:37
i used my compiles of gcc 4.4.1 to compile both x86 and x64 versions of x264 and it works fine.

compiling from the svn can be a dual edged sword - bugs are likely to appear as other ones are fixed,
this is why i only use official releases now.
(plus it saves time from building from weekly snaps and such)

Audionut
26th July 2009, 10:35
Subme10

http://git.videolan.org/?p=x264.git;a=commit;h=7733721e410acb96fdf740ca95d2a394b2a2b713

Tarutaru
26th July 2009, 13:58
x264.0.68.1189M.x86.exe (http://www.mediafire.com/?15zyntynzvx)

* patch -p1 < x264_hrd_pulldown.14_interlace.diff
* patch -p1 < x264_win_zone_parse_fix_05.diff
* pthread, gpac
* fprofiled, -msse4.2, -march=native(core i7)

JEEB
26th July 2009, 14:44
x264 r1189 32bit
download (http://jeeb.fiveforty.jp/x264/1189/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1189/relnotes.txt)

built on Jul 26 2009, gcc: 4.3.4 20090220 (prerelease) (x32.generic.Komisar)
fprofiled, -march=i686


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

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


patched with:

x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.14_interlace.diff

imk
27th July 2009, 14:01
x264-r1190M-imk-win.7z (http://imk.cx/pc/x264/x264-r1190M-imk-win.7z)
win_build_info.txt (http://imk.cx/pc/x264/win_build_info.txt)

bob0r
27th July 2009, 15:20
Need someone who can compile x264 64bit fprofiled from GIT (no patches), gcc prefered.
Techouse seems very busy.

If you can provide this please host it on a http host (i can provide if needed):
http://yourhost.com/whatever/revisionXXXX/x264.exe
Like that.
Also include:
md5sum x264.exe | awk '{print $1}' >x264.md5
please, thats the file i use and check for updates.
( http://yourhost.com/whatever/revisionXXXX/x264.md5 )

If you can provide this please post for me x264.exe --version, so i can update x264.nl

Maybe JEEB? :)

juGGaKNot
27th July 2009, 18:10
x264 r1189 32bit
download (http://jeeb.fiveforty.jp/x264/1189/x264.exe) ; release notes (http://jeeb.fiveforty.jp/x264/1189/relnotes.txt)

built on Jul 26 2009, gcc: 4.3.4 20090220 (prerelease) (x32.generic.Komisar)
fprofiled, -march=i686


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

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


patched with:

x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.14_interlace.diff


Was autovaq commited or still diff ?

A subme 10 build with autovaq ?

LoRd_MuldeR
27th July 2009, 18:13
Was autovaq commited or still diff ?

Yes. Look at the GIT ;)

http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=88b35c2d3bd86b42059e27db365752da9f2cd032

A subme 10 build with autovaq ?

You don't need a "SubME 10" build. SubME=10 is available in all regular builds (r1187 and later). Note that it requires Trellis=2.

juGGaKNot
27th July 2009, 19:41
Yes. Look at the GIT ;)

http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=88b35c2d3bd86b42059e27db365752da9f2cd032



You don't need a "SubME 10" build. SubME=10 is available in all regular builds (r1187 and later). Note that it requires Trellis=2.

subme 10 + autovaq ( that is if autovaq was not commited )

anyway tested, guess this means death to deathzones.

will the --preset be edited so that subme 10 is on @ slower and placebo ?

LoRd_MuldeR
27th July 2009, 19:53
subme 10 + autovaq ( that is if autovaq was not commited )

That is what you get with "--aq-mode 2" + "--trellis 2" + "--subme 10" using a standard (unpatched) build.

will the --preset be edited so that subme 10 is on @ slower and placebo ?

The "slower" preset uses Trellis=2 + SubMe=9, but "placebo" already uses Trellis=2 + SubMe=10.

I wonder whether SubMe=10 really is a "placebo" setting? ;)

juGGaKNot
27th July 2009, 20:09
That is what you get with "--aq-mode 2" + "--trellis 2" + "--subme 10" using a standard (unpatched) build.

Well yes if its not a diff anymore :)

What does the zone parse fix do ? now that autovaq is in i can move to a unpatched build.

The "slower" preset uses Trellis=2 + SubMe=9, but "placebo" already uses Trellis=2 + SubMe=10.

I wonder whether SubMe=10 really is a "placebo" setting? ;)

We will see when subme 11 is out :) i'm going to use it.

Does that mean it's any louder? (http://www.youtube.com/watch?v=EbVKWCpNFhY)

I do not have amps :|

Dark Shikari
27th July 2009, 20:11
We will see when subme 11 is out :) i'm going to use it.Does that mean it's any louder? (http://www.youtube.com/watch?v=EbVKWCpNFhY)

LoRd_MuldeR
27th July 2009, 20:38
Well yes if its not a diff anymore :)

As said before, AutoVAQ is committed ;)

What does the zone parse fix do ? now that autovaq is in i can move to a unpatched build.

See this post:
http://forum.doom9.org/showpost.php?p=1308492&postcount=7

I do not have amps :|

You don't need to have an amp at home to understand the joke :D

Selur
27th July 2009, 21:45
now that autovaq is in i can move to a unpatched build.
not before hrd_pulldown_interlace get's stable and finds it way into the maintree ;)

JEEB
27th July 2009, 22:24
x264 r1190 64bit unpatched:
download (http://jeeb.fiveforty.jp/x264/revision1190/x264.exe) ; hash (http://jeeb.fiveforty.jp/x264/revision1190/x264.md5)
________________________________________________________________________________

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

built on Jul 28 2009, gcc: 4.3.4 20090220 (prerelease) (x32.generic.Komisar)
fprofiled, -march=i686


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

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


patched with:

x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.15_interlace.diff

XhmikosR
28th July 2009, 05:04
Using JEEB's builds, r1190, r1189 and r1184 I get the following when x264 crashes:

avis [info]: 1280x720 @ 23.98 fps (1442 frames)
Assertion failed: dpb_output_delay < pow( 2, sps->vui.nal_hrd_parameters.i_dpb_o
utput_delay_length ), file encoder/set.c, line 643

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

cmd used:
x264 --profile high --slow-firstpass --pass 1 --quiet --bitrate 5000 --stats "1.stats" --level 4.1 --keyint 24 --min-keyint 1 --ref 1 --no-mixed-refs --bframes 3 --no-weightb --direct auto --chroma-qp-offset 0 --subme 1 --trellis 0 --analyse none --no-8x8dct --ipratio 1.1 --pbratio 1.1 --vbv-bufsize 50000 --vbv-maxrate 50000 --qcomp 0.5 --me dia --threads auto --thread-input --sar 1:1 --output NUL "test.avs" --mvrange 511 --aud --nal-hrd

If I use imk's build r1190 everything is fine.

Dark Shikari
28th July 2009, 05:10
If I use imk's build r1190 everything is fine.Note where it terminates. It's a bug in the nal-hrd patch.

XhmikosR
28th July 2009, 05:15
Yes, but the odd thing is that the same script, same cmd, same patches used, all the same, only the compiler is different, with imk's build I get no crashes. Anyway, I didn't know where else to report it. I hope it gets fixed. :)

Trahald
28th July 2009, 05:52
thats why i put the assert in there ;) rather the encoder die than a decoder down the line. (because w/out the assert the encode would have completed). will have a patch out shortly.

Trahald
28th July 2009, 06:42
Hrd 15.

JEEB
28th July 2009, 07:31
1190 builds rebuilt, re-uploaded (all but the unmodified one, which had no patches, so (ry)

Dark Shikari
28th July 2009, 07:34
1190 builds rebuilt, re-uploaded (all but the unmodified one, which had no patches, so (ry)Sorry, but your efforts were in vain! (http://git.videolan.org/?p=x264.git;a=commit;h=306c3ee4b1c3cae804185597305725d2484f21b9) :cool:

MythCreator
28th July 2009, 13:23
x264 rev.1192 unpatched x86
download (http://www.rayfile.com/files/55c7cc57-7b71-11de-832c-0019d11a795f/)

built on Jul 28 2009, gcc: 4.4.0 (release) (TDM-GCC)

fprofiled

juGGaKNot
28th July 2009, 14:29
What setting does the --tune fastdecode have ?

ahh nvm


+ else if( !strcasecmp( optarg, "fastdecode" ) )

+ {

+ param->b_deblocking_filter = 0;

+ param->b_cabac = 0;

+ param->analyse.b_weighted_bipred = 0;

+ }

x264 rev.1192 unpatched x86
download (http://www.rayfile.com/files/55c7cc57-7b71-11de-832c-0019d11a795f/)

built on Jul 28 2009, gcc: 4.4.0 (release) (TDM-GCC)

fprofiled

Try filefront/mediafire ?

hmm..I'll upload to FileFront

I found the download, well hidden!

Audionut
28th July 2009, 14:32
http://mailman.videolan.org/pipermail/x264-devel/2009-July/006096.html

+ else if( !strcasecmp( optarg, "fastdecode" ) )
+ {
+ param->b_deblocking_filter = 0;
+ param->b_cabac = 0;
+ param->analyse.b_weighted_bipred = 0;
+ }

MythCreator
28th July 2009, 14:53
Try filefront/mediafire ?

hmm..I'll upload to FileFront




x264 rev 1192 patched build

Download (http://www.filefront.com/14141557/x264-r1192-patched.exe)

built on Jul 28 2009, gcc: 4.4.0 (release) (TDM-GCC)

fprofiled

patched with:
x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.15_interlace.diff

gator1102
28th July 2009, 15:04
http://xeph.textcube.com/2/attach/x264.exe
x264 rev.1192 _ 32-bit binary with MP4 output

Intel C++ Compiler (icc) v11.1.038

Used patches:

x264_icc_03_win.diff
x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.15_interlace.diff
x264-r1183-threaded-slicetype-v17.diff

techouse
28th July 2009, 15:21
x264_x64_r1192_unpatched (http://techouse.project357.com/builds/revision1192/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1192/x264.md5)
GCC 4.4.0 20090524 (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

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

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

Patches used:

x264_hrd_pulldown.15_interlace.diff
x264_win_zone_parse_fix_05.diff

techouse
28th July 2009, 19:48
x264_x64_r1193_unpatched (http://techouse.project357.com/builds/revision1193/x264.exe) | MD5 (http://techouse.project357.com/builds/revision1193/x264.md5)
GCC 4.4.0 20090524 (x64.core2.Komisar), unpatched, generic, fprofiled

________________________________________________________________________________

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

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

Patches used:

x264_hrd_pulldown.15_interlace.diff
x264_win_zone_parse_fix_05.diff

JEEB
28th July 2009, 20:07
x264 r1193 64bit unpatched:
download (http://jeeb.fiveforty.jp/x264/revision1193/x264.exe) ; hash (http://jeeb.fiveforty.jp/x264/revision1193/x264.md5)

built on Jul 28 2009, gcc: 4.3.4 20090220 (prerelease) (x64.generic.Komisar)
fprofiled, otherwise defaults

________________________________________________________________________________

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

built on Jul 28 2009, gcc: 4.3.4 20090220 (prerelease) (x32.generic.Komisar)
fprofiled, -march=i686


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

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


patched with:

x264_win_zone_parse_fix_05.diff
x264_hrd_pulldown.15_interlace.diff


My help is probably unneeded, but since this is what my building script outputs nowadays, I'll be using this base I guess ;)