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

[aegisofrime]

thanks guys :)

i would love to see some comparison results on AMD vs Intel
builds, if someone have the time to do it...

I will do it. Although if something would to advise me on recommended testing methodologies to isolate the variables down to only AMD builds vs Generic/Intel builds, that will be helpful...

[captnes]

thanks guys :)

i would love to see some comparison results on AMD vs Intel
builds, if someone have the time to do it...

Real rough from memory last night I was getting about 2fps faster on an 8 minute 640x480 avs animation @ crf 18, everything else default with my X2 5600 Win7. I think it was about 13fps x32, 16fps x64 and 18fps AMD.

[Maccara]

I will do it. Although if something would to advise me on recommended testing methodologies to isolate the variables down to only AMD builds vs Generic/Intel builds, that will be helpful...

I'll be a bit surprised if you can get statistically significant differences.

Proper methodology would be to test various sources with various parameters to get results that would apply generally. That is still not counting, that you would need to test on multiple difference machines to get results that would apply for "everyone", but at least it would tell if there's any significant difference on at least some platform.

Maybe then analyzing the results with some mixed effects model (treating sources+params as random effects) would reveal the source of variability. Haven't used R much, but have been recommended lme4 package for mixed effects modeling. Standard anova probably would be masked/aliased by the difference between params/sources making it impossible to detect difference between exes only.

That was just from the top of my head to give some possible ideas. You need to also determine how many tests you need to have an adequate power for null hypothesis testing.

Edit: That being said, I've still compiled my own versions with -march=k8-sse3 "just to get the warm fuzzy feeling", even though I realize it probably doesn't make any significant difference. :) Will be nice if someone indeed will have the will and time to do proper testing.

[rack04]

Toolchain:
cross-mingw.gcc443.core2.20100124
gpac-cvs-0.4.6-DEV.core2.01272010
coreutils-5.97-2-msys-1.0.11-ext
pkg-config_0.23-3
glib_2.22.3-1
yasm-0.8.0
msys-1.0.11
x264_x86_r1471M (http://www.multiupload.com/S8MOYPYITT)

Patch:
x264_NAL-HRD.1.31.r1460_next.diff (http://komisar.gin.by/x.patch/last.used/x264_NAL-HRD.1.31.r1460_next.diff)
Build:
./configure --extra-cflags="-march=core2"
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled VIDS=parkrun.1280x720.yuv
LAVF/FFMS:
ffmpeg svn22127 and libswscale svn30800 (http://www.multiupload.com/998KMKC8SW)
ffms2 svn300 (http://www.multiupload.com/O8HRE25RN8)

[bob0r]

rack04, everyone:
Maybe you guys should mention you use SVN or GIT for ffmpeg. The revision numbers aren't the same for SVN or GIT.
x264.nl uses GIT for example, notice the completely different numbers! :devil:

[rack04]

Toolchain:
cross mingw gcc 4.4.3
gpac 0.4.6 DEV 01272010
pthreads GC static 20091019-1
yasm 0.8.0
x86:

x264_x86_r1471M (http://www.multiupload.com/MZUE0ROXTS)

FFmpeg Patch:
ffmpeg_static_pthreads (http://pastebin.ca/1822141)
x264 Patch:
x264_NAL-HRD.1.32 (http://pastebin.ca/1819862)
Build:
./configure --extra-cflags=-march=core2
Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled VIDS=pedestrian_1920x1080.yuv
x64:

x264_x64_r1471M (http://www.multiupload.com/NKJIANJOQA)

FFmpeg Patch:
ffmpeg_static_pthreads (http://pastebin.ca/1822141)
sws_x64_fix (http://pastebin.ca/1822143)
x264 Patch:
x264_NAL-HRD.1.32 (http://pastebin.ca/1819862)
Build:
./configure --extra-cflags=-march=core2 --host=x86_64-pc-mingw32 --cross-prefix=x86_64-pc-mingw32-
Platform: X86_64
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled VIDS=pedestrian_1920x1080.yuv
LAVF/FFMS:
ffmpeg svn22191 and libswscale svn30826 (http://www.multiupload.com/BR1Q4YS8S2)
ffms2 svn300 (http://www.multiupload.com/4I4Z1Z5C8O)

[outlaw.78]

x264 32bit & 64bit (http://www.mediafire.com/?wnaolhmotz5)

gcc 4.5.0 20100225 (experimental)
ffmpeg svn 22413
swscale svn 30879
ffms2 svn 305
pthreads 2.9.0.0 shared
x264 0.88.1471 amdfam10,fprofiled

[outlaw.78]

if u guys with 32bit windows have any problems with pthreads dll say so, i cant test the 32bit version.....

[Snowknight26]

Why's that?

[mara-]

Can anybody explain me what parameter --nal-hrd does? I can't find anywhere on the forum this explanation. I noticed that encoding is much slower with this parameter but, what it does? Thanks

Cheers ;)

[txporter]

Can anybody explain me what parameter --nal-hrd does? I can't find anywhere on the forum this explanation. I noticed that encoding is much slower with this parameter but, what it does? Thanks

Cheers ;)

It is for Blu-Ray compliance. See this thread (http://forum.doom9.org/showthread.php?t=152127).

[mara-]

OK, thanks. I sow the thread, but there is not explanation what for is the patch.

Cheers ;)

[rack04]

OK, thanks. I sow the thread, but there is not explanation what for is the patch.

Cheers ;)

Add NAL HRD parameters to the output stream; used for HD-DVD and Blu-ray compliancy. Depends on vbv-bufsize and vbv-maxrate to be set to be active.

[mara-]

Got it, thanks.

Cheers ;)

[rack04]

Toolchain:
cross-mingw.gcc443.core2.20100124
gpac-cvs-0.4.6-DEV.gc-static.core2.01272010
pthreads-2.9.0.0.gc-static.core2.20091019
glib_2.22.4-1
pkg-config_0.23-2
yasm-0.8.0
MSYS-1.0.11
msysDTK-1.0.1
msysCORE-1.0.14-1
bash-3.1.17-2
coreutils-5.97-2
m4-1.4.13-1
autoconf2.5-2.64-1
automake-1.11-1
libtool-2.2.7a-1
Builds:

x264_x64_r1510 (http://www.multiupload.com/DFDJPGR664)

./configure --prefix=/c/x264/x86_64-pc-mingw32 --extra-cflags=-march=core2 --host=x86_64-pc-mingw32 --cross-prefix=x86_64-pc-mingw32-

Platform: X86_64
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled VIDS=/f/x264/pedestrian_1920x1080.yuv

x264_x86_r1510 (http://www.multiupload.com/XAVPR0Z0XX)

./configure --prefix=/c/x264/i686-pc-mingw32 --extra-cflags=-march=core2

Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled VIDS=/f/x264/pedestrian_1920x1080.yuv

LAVF/FFMS:
ffmpeg svn22710 and libswscale svn30972 (http://www.multiupload.com/HNMHSTZR72)
ffms2 svn309 (http://www.multiupload.com/HHMUCYC23K)

[burfadel]

32 bit x264 r1510 anyone? x264.nl doesn't seem to be updating?... (its been a few hours)

[MatLz]

Here:
http://x264.fushizen.eu/

[burfadel]

Thanks for the link :)

[outlaw.78]

x264 x86 & x64 (http://www.mediafire.com/?nlliuzztzlt)

gcc 4.5.0 20100319 (experimental)
ffmpeg git 22712
ffms2 svn 309
pthreads 2.9.0.0 shared
x264 0.92.1510 x86,x64,amdfam10,fprofiled

[dev84]

Hi

Encoding with x264 r1510 from x264.nl in StaxRip i get:

------------------------------------------------------------
Error
------------------------------------------------------------

x264 failed with exit code -1

avs [info]: 1280x528p 0:0 @ 10000000/417083 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast FastShuffle SSEMisalign LZCNT
x264 [info]: profile High, level 4.0
x264 [error]: x264_encoder_encode failed
avs [info]: 1280x528p 0:0 @ 10000000/417083 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast FastShuffle SSEMisalign LZCNT
x264 [info]: profile High, level 4.0
avs [info]: 1280x528p 0:0 @ 10000000/417083 fps (cfr)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast FastShuffle SSEMisalign LZCNT
x264 [info]: profile High, level 4.0
x264 [error]: x264_encoder_encode failed


thx

[alexins]

Hi

Encoding with x264 r1510 from x264.nl in StaxRip i get:

thx

Processor AMD?
If so, look at my site, there is a builds for Phenom X3/X4, Phenom II, Athlon II, Athlon X2 7x50.

[olapanekala]

techouse we miss your excellent builds....

[dev84]

Processor AMD?
If so, look at my site, there is a builds for Phenom X3/X4, Phenom II, Athlon II, Athlon X2 7x50.

Same thing, 1510 from http://x264.fushizen.eu/ says "looks like we run out of mem" but on all three encoders; x264.nl, x264.fushizen.eu, xvidvideo.ru - build for PhenomII encoding stops almost in the same place except there is free memory, than why?

Settings:

--preset placebo --tune film --crf 20 --ref 8 --rc-lookahead 250 --merange 64

Screenshot shows error message and memory usage at crash.

http://img52.imageshack.us/img52/6199/x264.jpg

[tph]

Same thing, 1510 from http://x264.fushizen.eu/ says "looks like we run out of mem" but on all three encoders; x264.nl, x264.fushizen.eu, xvidvideo.ru - build for PhenomII encoding stops almost in the same place except there is free memory, than why?
32-bit processes can only allocate 2 GiB of memory which is not enough for high resolution encoding with really slow settings. Use a 64-bit version of x264.

[Warpman]

Same thing, 1510 from http://x264.fushizen.eu/ says "looks like we run out of mem" but on all three encoders; x264.nl, x264.fushizen.eu, xvidvideo.ru - build for PhenomII encoding stops almost in the same place except there is free memory, than why?

Settings:



Screenshot shows error message and memory usage at crash.


Lookahead 250 is insane! Of cause you will, as tph stated, exhaust the 2Gb limit per process.

Even placebo preset uses only 60 frames!
Don't touch any options if you don't know what are you doing... :/

[dev84]

I wosn`t aware there is 2GB limit per process in 32 bit M@OS, thx for help i sattle for 8 bframes not to exceed 2GB limit.
Lookahead 250 maby it is insane but if it is possible and one does have time; why not!

Thx again

[lexor]

Lookahead 250 maby it is insane but if it is possible and one does have time; why not!

Thx again

If one does have time, use 2-pass.

[Rumbah]

The 250 frames lookahead makes x264 exceed the 2 GB in your encode, not the number of b-frames.

[Dark Shikari]

The 250 frames lookahead makes x264 exceed the 2 GB in your encode, not the number of b-frames.It's a combination of the two, actually.

[dev84]

It's a combination of the two, actually.

Indeed, 8 bframes with lookahead 250 does not exceed 2GB

[Snowknight26]

You can't make a judgment as to whether it does or doesn't without additional information (such as resolution).

[dev84]

You can't make a judgment as to whether it does or doesn't without additional information (such as resolution).

Everything is in order, i stated the problem giving res + encoder cfg, problem was resolved, it works, there is no need for debate what is wise thing to do or not to do.

Thx.

[jpsdr]

Among the most common builds (that i know) : rack04, Jeeb or x264.nl.
Is there great differences ? Is one of them more efficient on XP64 (i7@965) ?
Or are they globaly the same ?

[JEEB]

Among the most common builds (that i know) : rack04, Jeeb or x264.nl.
Is there great differences ? Is one of them more efficient on XP64 (i7@965) ?
Or are they globaly the same ?

x264.nl is currently using my builds (if we're talking about 64bit, automatizing 32bit is rather easy and jarod has been doing that by himself all the time IIRC). If there is any difference between rack's and mine, it'd probably end up being rather small :) (I would guess GCC's march settings + other optimizations, and/or intel's C compiler might give some speedup, but personally I've been just fine with standard GCC builds -- esp. because with GCC you never know when it might actually do the opposite from what you'd think).

My builds are nowadays generally without -march settings, with just standard configure (those builds that went onto x264.nl were always without -march=core2).

[CpT]

I've been using your build Jeeb with no issues on windows 7 64bit and the new I7980x @ 4.1ghz ;)

I would love to test out an x264 intel C build though using the latest x264 and this new cpu. They were faster for me, but only slightly.

[rack04]

Toolchain:
cross-mingw.gcc443.core2.20100124
gpac-cvs-0.4.6-DEV.rev5
pthreads-2.9.0.0.gc-static.core2.20091019
glib_2.24.0-1
pkg-config_0.23-3
yasm-r2310
MSYS-1.0.11
bash-3.1.17-2
coreutils-5.97-2
m4-1.4.13-1
autoconf2.5-2.64-1
automake-1.11-1
libtool-2.2.7a-1
LAVF/FFMS Builds:

ffmpeg svn22811 and libswscale svn31026 (http://www.multiupload.com/SDSTJEBHAT)
ffms2 svn309 (http://www.multiupload.com/FDNQ3NGGUV)
FFmpeg Patches:
ffmpeg_static_pthreads_v2 (http://pastebin.com/NTPxc4c5)
sws_x64_fix_v2 (http://pastebin.com/aUHckFQF)
x264 Builds:

x264_x86_r1523 (http://www.multiupload.com/NH7PEFHACQ)

./configure --prefix=/c/x264/i686-pc-mingw32 --extra-cflags=-march=core2

Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled VIDS=/c/x264/pedestrian_1920x1080.yuv
x264_x64_r1523 (http://www.multiupload.com/WYEG2M1SJY)

./configure --prefix=/c/x264/x86_64-pc-mingw32 --extra-cflags=-march=core2 --host=x86_64-pc-mingw32 --cross-prefix=x86_64-pc-mingw32-

Platform: X86_64
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled VIDS=/c/x264/pedestrian_1920x1080.yuv

[outlaw.78]

x264 0.92.1523 x64 & x86 (http://www.mediafire.com/?ntimk4widoo)

gcc 4.5.0 20100406 (pre-release)
ffmpeg svn 22815
ffms2 svn 309
pthreads 2.9.0.0 static (thanks to rack04 for providing the patches)
x264 0.92.1523 x86,x64,amdfam10,fprofiled

[burfadel]

x264 0.92.1523 x64 & x86 (http://www.mediafire.com/?ntimk4widoo)

gcc 4.5.0 20100406 (pre-release)
ffmpeg svn 22815
ffms2 svn 309
pthreads 2.9.0.0 static (thanks to rack04 for providing the patches)
x264 0.92.1523 x86,x64,amdfam10,fprofiled

With the x86 version, the quality of the output is really quite bad - its extremely noticeable, and the filesize is much smaller than it should be. I only tried CRF mode, since this is the one I typically use. I traced the issue back to mb-tree, with mb-tree on (default) the output is bunged, with mb-tree off its fine! Your previous r1310 build also had the same issue. Other builds work fine with mb-tree on, so I'm not sure what part of your compile chain breaks mb-tree.

This is on an Intel Q9400.

[burfadel]

In regards to build r1323 (the working builds) I've noticed a slight increase in speed, PSNR and SSIM (did a test with r1310 and r1323 out of interest).

[outlaw.78]

With the x86 version, the quality of the output is really quite bad - its extremely noticeable, and the filesize is much smaller than it should be. I only tried CRF mode, since this is the one I typically use. I traced the issue back to mb-tree, with mb-tree on (default) the output is bunged, with mb-tree off its fine! Your previous r1310 build also had the same issue. Other builds work fine with mb-tree on, so I'm not sure what part of your compile chain breaks mb-tree.

This is on an Intel Q9400.

i compile for amd only, so you should not run it on intel cpus, use rack04 builds instead....

[burfadel]

Ah ok :) at least it does show that there is a difference between compiling for AMD or Intel!

[LoRd_MuldeR]

Ah ok :) at least it does show that there is a difference between compiling for AMD or Intel!

But that doesn't explain why you got different output! As long as VBV isn't involved and as long as "--non-deterministic" isn't specified, all builds should give identical output for identical input/settings. If the build was compiled for a different type of CPU than yours, then two things happen: First of all, CPU instructions may be used in the compiled C code that aren't supported by your CPU. I don't think this applies here, but even if it did, you would simply encounter a crash ("illegal instruction"), but not borked output. The second thing is that the "cycles per instruction" that the compiler assumed for the target CPU don't match your CPU, which will result in code that won't run optimally (i.e. not at the full speed that it could run at) on your CPU, but the code still will (or at least should) run correctly! Therefore I rather suspect a miscompilation by GCC, than a CPU-type related issue. Consequently I'd suggest to outlaw.78 to check the output from his build against a reference build...

[laserfan]

My builds...Wondering JEEB why r1523 build of yours is suddenly 8,500KB where before was 1,200KB???

[LoRd_MuldeR]

Wondering JEEB why r1523 build of yours is suddenly 8,500KB where before was 1,200KB???

FFM2 + libavcodec + libavformat !?

[burfadel]

I tried lots of different settings, and in each case I got borked output in CRF mode with mb-tree on. I just tried the amdfam10 build of x264 r1323 from xvidvideo.ru and that has the exact same problem as outlaw.78's build, borked output with mb-tree on, whereas with the core2 build from xvidvideo.ru it works fine.

Edit:
On a short clip, here's the output from x264. I enabled PSNR and SSIM just for the comparison.

All builds except for those compiled for amdfam10 by Outlaw.78 and xvidvideo.ru:
x264 [info]: frame I:6 Avg QP:22.07 size: 23195 PSNR Mean Y:44.37 U:49.50 V:49.18 Avg:45.49 Global:45.38
x264 [info]: frame P:318 Avg QP:24.05 size: 6223 PSNR Mean Y:40.30 U:47.38 V:47.10 Avg:41.64 Global:41.53
x264 [info]: frame B:977 Avg QP:29.84 size: 1198 PSNR Mean Y:39.96 U:47.12 V:46.85 Avg:41.31 Global:41.17
x264 [info]: consecutive B-frames: 0.3% 2.2% 35.2% 11.4% 2.7% 48.2% 0.0% 0.0%
x264 [info]: mb I I16..4: 1.7% 85.1% 13.2%
x264 [info]: mb P I16..4: 0.4% 8.3% 1.1% P16..4: 48.0% 23.9% 8.6% 0.6% 0.8% skip: 8.4%
x264 [info]: mb B I16..4: 0.0% 0.4% 0.0% B16..8: 37.6% 5.6% 1.3% direct: 2.2% skip:52.9% L0:29.6% L1:54.0% BI:16.4%
x264 [info]: 8x8 transform intra:85.4% inter:60.2%
x264 [info]: direct mvs spatial:99.6% temporal:0.4%
x264 [info]: coded y,uvDC,uvAC intra: 88.2% 83.8% 50.1% inter: 13.9% 15.0% 2.4%
x264 [info]: i16 v,h,dc,p: 31% 17% 4% 48%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 25% 17% 8% 5% 7% 9% 8% 11% 11%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 21% 14% 4% 7% 11% 13% 11% 10% 10%
x264 [info]: Weighted P-Frames: Y:0.0%
x264 [info]: ref P L0: 56.4% 17.9% 18.5% 2.8% 3.1% 1.4%
x264 [info]: ref B L0: 92.1% 6.6% 0.9% 0.3%
x264 [info]: ref B L1: 96.9% 3.1%
x264 [info]: SSIM Mean Y:0.9812923
x264 [info]: PSNR Mean Y:40.066 U:47.194 V:46.920 Avg:41.408 Global:41.271 kb/s:606.06
encoded 1301 frames, 27.85 fps, 606.06 kb/s

Results for the amdfam10 builds by Outlaw.78 and xvidvideo.ru. Same settings as Intel builds:
x264 [info]: frame I:6 Avg QP:31.86 size: 9254 PSNR Mean Y:36.56 U:43.90 V:43.33 Avg:37.91 Global:37.46
x264 [info]: frame P:318 Avg QP:33.68 size: 2079 PSNR Mean Y:34.78 U:42.73 V:42.01 Avg:36.17 Global:36.00
x264 [info]: frame B:977 Avg QP:30.32 size: 2005 PSNR Mean Y:36.80 U:43.81 V:43.16 Avg:38.11 Global:37.98
x264 [info]: consecutive B-frames: 0.3% 2.2% 35.2% 11.4% 2.7% 48.2% 0.0% 0.0%
x264 [info]: mb I I16..4: 5.7% 87.0% 7.3%
x264 [info]: mb P I16..4: 0.7% 5.4% 0.3% P16..4: 40.5% 9.3% 3.9% 0.0% 0.0% skip:39.9%
x264 [info]: mb B I16..4: 0.1% 0.4% 0.0% B16..8: 43.1% 9.1% 1.5% direct: 5.6% skip:40.2% L0:41.1% L1:49.1% BI: 9.7%
x264 [info]: 8x8 transform intra:84.3% inter:79.7%
x264 [info]: direct mvs spatial:99.3% temporal:0.7%
x264 [info]: coded y,uvDC,uvAC intra: 69.5% 62.8% 22.2% inter: 15.5% 15.4% 0.6%
x264 [info]: i16 v,h,dc,p: 37% 24% 5% 34%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 21% 12% 6% 7% 8% 12% 10% 12% 12%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 12% 5% 6% 10% 12% 11% 10% 10%
x264 [info]: Weighted P-Frames: Y:0.0%
x264 [info]: ref P L0: 39.5% 40.4% 13.9% 2.2% 3.1% 1.0%
x264 [info]: ref B L0: 64.3% 31.4% 3.0% 1.3%
x264 [info]: ref B L1: 97.6% 2.4%
x264 [info]: SSIM Mean Y:0.9602218
x264 [info]: PSNR Mean Y:36.305 U:43.546 V:42.882 Avg:37.639 Global:37.405 kb/s:493.15
encoded 1301 frames, 37.53 fps, 493.15 kb/s

The PSNR and SSIM are lower, but by no means show how bad the output actually is.

Edit 2: Resolution used was 512,384 for the comparison.

[LoRd_MuldeR]

I tried lots of different settings, and in each case I got borked output in CRF mode with mb-tree on. I just tried the amdfam10 build of x264 r1323 from xvidvideo.ru and that has the exact same problem as outlaw.78's build, borked output with mb-tree on, whereas with the core2 build from xvidvideo.ru it works fine.

Still, this most likely indicates a bug in GCC 4.5.0 with respect to "-march=amdfam10", instead of an incompatibility between "AMD-optimized" builds any your Intel CPU.

Using "optimizations" that break compatibility to certain CPU types, although these CPU types support all the required instruction sets, is something that I'd expect from ICC only :D

[burfadel]

I'm suspecting a GCC error too, I wonder if on AMD systems the same output problem occurs?

[Midzuki]

Wondering JEEB why r1523 build of yours is suddenly 8,500KB where before was 1,200KB???

BTW, Komisar's x264 Mod == 6.12MB,
whereas "the most official" :) x264 build == 6.08MB.
And of course, Komisar's x264 includes AVI output :D

Anyway: it seems ppl have forgotten what 7-zip exists for. :devil:

[LoRd_MuldeR]

I'm suspecting a GCC error too, I wonder if on AMD systems the same output problem occurs?

I would assume so! Will check this on my AMD machine when I return home...

[rack04]

Toolchain:
cross-mingw.gcc443.core2.20100124
gpac-cvs-0.4.6-DEV.rev5
pthreads-2.9.0.0.gc-static.core2.20091019
glib_2.24.0-1
pkg-config_0.23-3
yasm-r2310
MSYS-1.0.11
bash-3.1.17-2
coreutils-5.97-2
m4-1.4.13-1
autoconf2.5-2.64-1
automake-1.11-1
libtool-2.2.7a-1
LAVF/FFMS Builds:

ffmpeg SVN-r22822M and libswscale SVN-r31027M (http://www.multiupload.com/5TDLNKAQZJ)
ffms2 SVN-r309M (http://www.multiupload.com/NQCK47BH7S)
LAVF/FFMS Patches:
ffmpeg_static_pthreads_v2 (http://pastebin.com/NTPxc4c5) <angustia>
libswscale_x64_fix_v2 (http://pastebin.com/aUHckFQF) <BugMaster>
ffms2_threads_fix (http://pastebin.com/WZP1YCcW) <komisar>
x264 Builds:

x264_x64_r1523M (http://www.multiupload.com/V2AOQC8POF)

./configure --prefix=/c/x264/x86_64-pc-mingw32 --extra-cflags=-march=core2 --host=x86_64-pc-mingw32 --cross-prefix=x86_64-pc-mingw32-

Platform: X86_64
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
avi output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled VIDS=/f/x264/pedestrian_1920x1080.yuv
x264_x86_r1523M (http://www.multiupload.com/XB1ENWPV00)

./configure --prefix=/c/x264/i686-pc-mingw32 --extra-cflags=-march=core2

Platform: X86
System: MINGW
asm: yes
avs input: yes
lavf input: yes
ffms input: yes
mp4 output: yes
avi output: yes
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
make fprofiled VIDS=/f/x264/pedestrian_1920x1080.yuv
x264 Patches:
x264_sws_typecast (http://pastebin.com/kVYc1BYn) <komisar>
x264_demuxer_threads (http://pastebin.com/XUFQYemT) <komisar>
x264_thread_pool_v2.7 (http://pastebin.com/yCd3bXCP) <BugMaster>
x264_fix_float_point_exception (http://pastebin.com/mG4gi0hW) <BugMaster>
x264_avi_output.v3 (http://pastebin.com/e54DR1vb) <BugMaster>