Compiling x264 on 32 & 64 Bit Windows - Guide.

[the_ether]

msys uses the linux path style so C:\ is /c/ not c/ like you have it there.

Well spotted. Now things work. Thank you - and to outlaw78 too.

I'm pretty sure I followed the setup instructions correctly. I'm surprised this path issue hasn't come up before.

[outlaw78]

msys uses the linux path style so C:\ is /c/ not c/ like you have it there.

so you told gcc to look in a directory that doesn't exist, which explains why it can't find it there.

y y was late and almost sleeping on chair...

[JEEB]

Probably a wide-known bug by now, but the current HEAD (1460) crashes during fprofile on 64bit Windows (64bit Linux might be affected as well).

Which revision is the culprit is not yet straightly said, but it is very possible that some of the new ASM stuff broke it.

I didn't have the time to make a debug binary yet to see the place it crashes at explicitly, as I have to fly away to university right now, but just thought to let people know while I was at it.

[Bugi]

As I also have a Phenom II core (actually: Athlon II X3) and am running 7 x64, I'm also going to look at building the stuff myself (never done that before). It makes quite a difference speedwise, I've found out from the earlier posted K10 build.
However, in the starting post, the current stable GCC 4.4.3 version is mentioned.
I used to get my builds from xvidvideo.ru, which contains builds where GCC 4.5.0 (SVN) is used and which have never failed on me.
Would this also be possible to use and if so, would it benefit the process in any way?

(PS. I've been a doom9 visitor for ages, and was quite surprised to find out about the existence of this forum. What is the relation to doom9 and is it supposed to be the 'successor'?)

[rack04]

(PS. I've been a doom9 visitor for ages, and was quite surprised to find out about the existence of this forum. What is the relation to doom9 and is it supposed to be the 'successor'?)

http://doom10.org/index.php?topic=17.0

[Bugi]

I used to get my builds from xvidvideo.ru, which contains builds where GCC 4.5.0 (SVN) is used and which have never failed on me.
Would this also be possible to use and if so, would it benefit the process in any way?

Any thoughts on this, anyone?

[qyot27]

I don't know what kind of advantages/disadvantages 4.5.0 has for x264, but I know that Sherpya went back to the 4.2 branch for their mplayer/mencoder builds because of problems getting 4.5.0 to play nice with those or something.  I read it on the front page (http://oss.netfarm.it/mplayer-win32.php), but that was a few months ago.  Unfortunately, archive.org doesn't have any revisions of the page from 2009, so I can't double-check exactly when it was.

More than likely you're not going to find substantial differences in compilation of x264 between versions of GCC, any possible miscompilation problems aside.  Heck, comparisons I've made between 3.4.5 and 4.4.2 (which were totally unscientific, btw) didn't really show much of a gain in performance - for a couple of tests, 4.4.2 actually was slower than the 3.4.5 builds by a few hundreths or tenths of a frame-per-second - and this was on a system that's pretty much a dinosaur compared to common setups now.  The time spent compiling might be where the bigger difference lies, but I've never done a comparison like that - I mean, it takes my computer the better part of an hour to compile ffmpeg (~5-10 minutes for ./configure, 30-40 for the actual make process), and even though x264 takes maybe 5 minutes tops, I don't really feel like taking up run after run to determine any kind of speed increase in the compiler.

My concern would simply be whether the output from x264 is okay.  I can never seem to remember the command to make it run an md5sum check on the output, but that can help you determine if a build you're using is miscompiled (as long as you're using something you know was properly built as your control).

[kemuri-_9]

My concern would simply be whether the output from x264 is okay.  I can never seem to remember the command to make it run an md5sum check on the output, but that can help you determine if a build you're using is miscompiled (as long as you're using something you know was properly built as your control).

you seem to be thinking of x264 [opts] -o - | md5sum
this is a useful test, but the md5sum changes for a file whenever there's a new revision or the settings are different, so knowing the md5sum is correct or not usually takes others' md5sums to compare against.

on the overall basis, any version of gcc is fine as long as it doesn't miscompile x264, this is the critical key.

[STaRGaZeR]

Guys, I'm getting a lot of undefined reference errors when compiling for x86_64. I'm using mingw from the mingw64 sourceforge project, ffdshow64 builds just fine with it. Example, I run "./configure --cross-prefix=x86_64-w64-mingw32- --host=x86_64-w64-mingw32", then make:

Code: [Select]

$ make
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o x264.o
 x264.c
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o input/
timecode.o input/timecode.c
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o input/
yuv.o input/yuv.c
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o input/
y4m.o input/y4m.c
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o output
/raw.o output/raw.c
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o output
/matroska.o output/matroska.c
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o output
/matroska_ebml.o output/matroska_ebml.c
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o output
/flv.o output/flv.c
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o output
/flv_bytestream.o output/flv_bytestream.c
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o input/
avs.o input/avs.c
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o input/
thread.o input/thread.c
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o common
/mc.o common/mc.c
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o common
/predict.o common/predict.c
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o common
/pixel.o common/pixel.c
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o common
/macroblock.o common/macroblock.c
common/macroblock.c: In function 'x264_macroblock_cache_init':
common/macroblock.c:735: warning: 'luma_plane_size' may be used uninitialized in
 this function
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o common
/frame.o common/frame.c
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o common
/dct.o common/dct.c
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o common
/cpu.o common/cpu.c
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o common
/cabac.o common/cabac.c
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o common
/common.o common/common.c
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o common
/mdate.o common/mdate.c
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o common
/rectangle.o common/rectangle.c
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o common
/set.o common/set.c
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o common
/quant.o common/quant.c
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o common
/vlc.o common/vlc.c
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o encode
r/analyse.o encoder/analyse.c
encoder/analyse.c: In function 'x264_intra_rd_refine':
encoder/analyse.c:1035: warning: 'pels_v[6]' may be used uninitialized in this f
unction
encoder/analyse.c:1035: warning: 'pels_v[5]' may be used uninitialized in this f
unction
encoder/analyse.c:1035: warning: 'pels_v[4]' may be used uninitialized in this f
unction
encoder/analyse.c:1035: warning: 'pels_v[3]' may be used uninitialized in this f
unction
encoder/analyse.c:1035: warning: 'pels_v[2]' may be used uninitialized in this f
unction
encoder/analyse.c:1035: warning: 'pels_v[1]' may be used uninitialized in this f
unction
encoder/analyse.c:1035: warning: 'pels_v[0]' may be used uninitialized in this f
unction
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o encode
r/me.o encoder/me.c
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o encode
r/ratecontrol.o encoder/ratecontrol.c
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o encode
r/set.o encoder/set.c
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o encode
r/macroblock.o encoder/macroblock.c
encoder/macroblock.c: In function 'x264_macroblock_probe_skip':
encoder/macroblock.c:912: warning: 'mvp[1]' may be used uninitialized in this fu
nction
encoder/macroblock.c:912: warning: 'mvp[0]' may be used uninitialized in this fu
nction
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o encode
r/cabac.o encoder/cabac.c
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o encode
r/cavlc.o encoder/cavlc.c
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o encode
r/encoder.o encoder/encoder.c
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o encode
r/lookahead.o encoder/lookahead.c
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o common
/x86/mc-c.o common/x86/mc-c.c
gcc -O3 -ffast-math  -Wall -I. -std=gnu99 -s -fomit-frame-pointer   -c -o common
/x86/predict-c.o common/x86/predict-c.c
yasm -f win32 -m amd64 -DPREFIX -DARCH_X86_64 -Icommon/x86/ -o common/x86/cabac-
a.o common/x86/cabac-a.asm
yasm -f win32 -m amd64 -DPREFIX -DARCH_X86_64 -Icommon/x86/ -o common/x86/dct-a.
o common/x86/dct-a.asm
yasm -f win32 -m amd64 -DPREFIX -DARCH_X86_64 -Icommon/x86/ -o common/x86/debloc
k-a.o common/x86/deblock-a.asm
yasm -f win32 -m amd64 -DPREFIX -DARCH_X86_64 -Icommon/x86/ -o common/x86/mc-a.o
 common/x86/mc-a.asm
yasm -f win32 -m amd64 -DPREFIX -DARCH_X86_64 -Icommon/x86/ -o common/x86/mc-a2.
o common/x86/mc-a2.asm
yasm -f win32 -m amd64 -DPREFIX -DARCH_X86_64 -Icommon/x86/ -o common/x86/pixel-
a.o common/x86/pixel-a.asm
yasm -f win32 -m amd64 -DPREFIX -DARCH_X86_64 -Icommon/x86/ -o common/x86/predic
t-a.o common/x86/predict-a.asm
yasm -f win32 -m amd64 -DPREFIX -DARCH_X86_64 -Icommon/x86/ -o common/x86/quant-
a.o common/x86/quant-a.asm
yasm -f win32 -m amd64 -DPREFIX -DARCH_X86_64 -Icommon/x86/ -o common/x86/sad-a.
o common/x86/sad-a.asm
yasm -f win32 -m amd64 -DPREFIX -DARCH_X86_64 -Icommon/x86/ -o common/x86/cpu-a.
o common/x86/cpu-a.asm
yasm -f win32 -m amd64 -DPREFIX -DARCH_X86_64 -Icommon/x86/ -o common/x86/dct-64
.o common/x86/dct-64.asm
x86_64-w64-mingw32-ar rc libx264.a common/mc.o common/predict.o common/pixel.o c
ommon/macroblock.o common/frame.o common/dct.o common/cpu.o common/cabac.o commo
n/common.o common/mdate.o common/rectangle.o common/set.o common/quant.o common/
vlc.o encoder/analyse.o encoder/me.o encoder/ratecontrol.o encoder/set.o encoder
/macroblock.o encoder/cabac.o encoder/cavlc.o encoder/encoder.o encoder/lookahea
d.o common/x86/mc-c.o common/x86/predict-c.o common/x86/cabac-a.o common/x86/dct
-a.o common/x86/deblock-a.o common/x86/mc-a.o common/x86/mc-a2.o common/x86/pixe
l-a.o common/x86/predict-a.o common/x86/quant-a.o common/x86/sad-a.o common/x86/
cpu-a.o common/x86/dct-64.o
x86_64-w64-mingw32-ranlib libx264.a
gcc -o x264.exe x264.o input/timecode.o input/yuv.o input/y4m.o output/raw.o out
put/matroska.o output/matroska_ebml.o output/flv.o output/flv_bytestream.o input
/avs.o input/thread.o libx264.a -lpthread -s
x264.o:x264.c:(.text+0x56): undefined reference to `x264_mdate'
x264.o:x264.c:(.text+0x3eb): undefined reference to `x264_encoder_open_92'
x264.o:x264.c:(.text+0x407): undefined reference to `x264_encoder_parameters'
x264.o:x264.c:(.text+0x48b): undefined reference to `x264_mdate'
x264.o:x264.c:(.text+0x6fb): undefined reference to `x264_encoder_encode'
x264.o:x264.c:(.text+0xce5): undefined reference to `x264_encoder_delayed_frames
'
x264.o:x264.c:(.text+0xd22): undefined reference to `x264_encoder_encode'
x264.o:x264.c:(.text+0xe5f): undefined reference to `x264_mdate'
x264.o:x264.c:(.text+0xe8d): undefined reference to `x264_encoder_close'
x264.o:x264.c:(.text+0xfb4): undefined reference to `x264_encoder_headers'
x264.o:x264.c:(.text+0x2320): undefined reference to `x264_param_default'
x264.o:x264.c:(.text+0x23eb): undefined reference to `x264_param_default_preset'

x264.o:x264.c:(.text+0x24d3): undefined reference to `x264_param_parse'
x264.o:x264.c:(.text+0x2915): undefined reference to `x264_param_apply_profile'
x264.o:x264.c:(.text+0x2bc2): undefined reference to `x264_reduce_fraction'
x264.o:x264.c:(.text+0x2bdc): undefined reference to `x264_reduce_fraction'
x264.o:x264.c:(.text+0x2e15): undefined reference to `x264_levels'
x264.o:x264.c:(.text+0x2e2f): undefined reference to `x264_levels'
x264.o:x264.c:(.text+0x2e81): undefined reference to `x264_param_apply_fastfirst
pass'
x264.o:x264.c:(.text+0x3447): undefined reference to `x264_cpu_num_processors'
x264.o:x264.c:(.text+0x3463): undefined reference to `x264_levels'
input/timecode.o:timecode.c:(.text+0x102a): undefined reference to `x264_reduce_
fraction'
input/yuv.o:yuv.c:(.rdata+0x48): undefined reference to `x264_picture_alloc'
input/yuv.o:yuv.c:(.rdata+0x54): undefined reference to `x264_picture_clean'
input/y4m.o:y4m.c:(.text+0x654): undefined reference to `x264_reduce_fraction'
input/y4m.o:y4m.c:(.text+0x718): undefined reference to `x264_reduce_fraction'
input/y4m.o:y4m.c:(.rdata+0x100): undefined reference to `x264_picture_alloc'
input/y4m.o:y4m.c:(.rdata+0x10c): undefined reference to `x264_picture_clean'
collect2: ld returned 1 exit status
make: *** [x264.exe] Error 1
Any suggestions? Also, how can I compile with ffms, lavf and mp4 support? An addition to the guide would be nice.

[kemuri-_9]

something seems off as you are compiling with 'gcc' while ranlib and ar are using the proper 'x86_64-w64-mingw32-' prefix you indicated.
'gcc' here should be 'x86_64-w64-mingw32-gcc'
most people here don't use the mingw64 project binaries so you might have a specific issue to solve revolving around that.

[STaRGaZeR]

You're right, I was compiling with 32-bit gcc. I renamed the file and got a "gcc not found error". After investigating the cause was the CC variable with value "gcc" I had in my enviroment variables. This is required to compile ffdshow, but causes configure to always put CC=gcc in config.mak, even when the prefix is set to xxxx for example. If I manually edit CC in config.mak it compiles with x86_64-pc-mingw32-gcc but I get a "cannot find -lwsock32" error. The only solution so far is to delete the CC variable. Do you know how to "fix" this so I don't have to manually delete and create CC when I want to compile ffdshow/x264?

I've also managed to compile x264 with mp4 and lavf support thanks to komisar's libpack for x264 found here, but in ffms I always get a big no. Any suggestions here? That pack is supposed to have the files needed for ffms too, right?

One last thing, is it possible to create a one click compile script for MSYS like I do with .bat files and Windows' cmd?

Thanks for the help!

[Linyx]

Any suggestions? Also, how can I compile with ffms, lavf and mp4 support? An addition to the guide would be nice.

Lavf and mp4 should be in there.  As for ffms, I haven't had the time (or knowledge ) to get that figured out yet.

[kemuri-_9]

-lwsock32 is the winsock1 library, it is only specifically useful for windows 95 systems which don't natively have winsock2 (-lws2_32) which has been around since windows 98 or so (in fact the winsock1 library is just a wrapper around winsock2 on most of these platforms).
as such, x86_64 does not have winsock1, use -lws2_32 for winsock2 instead.

as to your issue:
A) tell ffdshow to not be dick heads and require CC to be set.
B) try manually setting CC for x264's configure, e.g.

Code: [Select]

CC=x86_64-w64-mingw32-gcc ./configure --cross-prefix=x86_64-w64-mingw32- --host=x86_64-pcmingw32
you could try similarly trying doing this for when you compile ffdshow instead.

[STaRGaZeR]

B) did the trick, thanks! A) would be the ideal solution, but I don't think ffdshow developers have the time to do that.

Lavf and mp4 should be in there.  As for ffms, I haven't had the time (or knowledge ) to get that figured out yet.

Ouch, I completely missed that point 

I caught this in config.log:

checking whether ffms2 version is at least 2.13.1... no

There are a lot of errors in there.

[kemuri-_9]

there are 2 tests for ffms2
A) shared lib test
B) static lib test

shared lib test assumes that the library has already been linked against stdc++ and when it fails, it'll spit out a bazillion link failures relating to c++ things.
the 2nd test links with stdc++ as is necessary for when linking against static ffms2.

as to compiling ffms2 it'll likely be something as

Code: [Select]

./configure --host=x86_64-w64-mingw32
makefor you with that cross-prefix you have to get it to go...
give or take parts about whether you have pkg-config or not and ffmpeg's .pcs installed to where pkg-config looks.
e.g. i do not so i also need to specify

Code: [Select]

FFMPEG_LIBS="-lswscale -lavcodec -lpostproc -lavutil -lz -lbz2 -lavifil32"on the configure as well (-lavifil32 is because i compile ffmpeg with avisynth support, even on x64)

[STaRGaZeR]

Good news, I managed to compile x264 with ffms2 thanks to komisar's lastest libpack, Linyx please test if it works for you so it can be added to the guide.

One thing that intrigues me is that x264.exe es ~1MB smaller than x264.nl's x64 build, and it seems I've compiled it with the same inputs, outputs, fprofiled, etc. My build works fine though.

[komisar]

STaRGaZeR, in earlier libpack i forgot to disable audio decoders in ffmpeg... now only video decoders present in ffmpeg.

[qyot27]

One last thing, is it possible to create a one click compile script for MSYS like I do with .bat files and Windows' cmd?

Not a one-click solution, but you can compose a shell script and then execute it using MSys bash.  It would be laid out like this (adapt as needed for other compilation steps):

#!/bin/bash -x
cd ffmpeg
./configure --prefix=$HOME/ffms2_build --enable-gpl --enable-postproc --enable-memalign-hack --enable-pthreads --enable-avisynth --enable-runtime-cpudetect
make
make install

Remember that the # and ! in the first line cannot have spaces between them if you want the -x parameter to work the way it's supposed to (which is what tells the script to print every command it gives like a .bat file normally does - otherwise you'd see everything run together).  After composing such a script (let's say it was named buildscript), you would then do the following in a regular MSys session:

chmod +x buildscript
./buildscript

The chmod line may not be necessary for MSys on Windows, but on *nix systems (and possibly Cygwin) it gives the text files execution permission.  The ./ in the second line tells bash to treat the file as an executable on the PATH and run normally.  If you had the script installed to system the ./ wouldn't be necessary.

[STaRGaZeR]

Thanks qyot, that info helped a lot.

Has anyone considered using ffmpeg-mt? With high resolution sources and fast presets the decoder is way slower than x264 itself.

[checkers]

Here's a test build. I'm too lazy to see if the decoding is actually multithreaded, can someone else confirm?
http://www.bluebottle.net.au/x264.exe

Nothing special done, I built x264 in mingw on linux as per my instructions, just replacing ffmpeg with ffmpeg-mt. The steps to get the ffmpeg-mt repository are these:

Code: [Select]

git clone git://gitorious.org/~astrange/ffmpeg/ffmpeg-mt.git ffmpeg-mt
cd ffmpeg-mt/
git submodule init
git submodule update


[pasteeater]

...
Yasm
Download yasm, the latest stable version is:
Yasm-0.8.0-win32.exe -- Copy this file to the MinGW\bin folder, and rename it to yasm.exe.
...

Yasm 1.0.0 is now the latest stable available.

[CF]

Minor note:

the yasm (Yasm-1.0.0-win32.exe) pointed to in the first post of this forum (updated on April 19th) seems to have Windows-like command line syntax (for example: "yasm.exe /version"), rather than the older unix-style of, for example, yasm-0.6.2-win32.exe ("yasm --version").

This causes problems with "./configure" script the current/latest git deposit of x264, as run within MSYS, which expects the Unix-style syntax.

Today's x264.exe (version 0.93.1542) compiles successfully with yasm-0.6.2-win32.exe.

[kemuri-_9]

the link is pointing to the wrong version, it should be pointing to
yasm-1.0.0-win32.exe

[Midzuki]

Today's x264.exe (version 0.93.1542) compiles successfully with yasm-0.6.2-win32.exe.

"Today's x264" is 0.94.1563 already. :-)

[eViLsTieFel]

I've followed the instructions to the letter (as far as I can tell), but unfortunatelly I get an error when trying to compile for 64 bit using

Code: [Select]

./configure --cross-prefix=x86_64-pc-mingw32- --host=x86_64-pc-mingw32
$ ./configure --cross-prefix=x86_64-pc-mingw32 --host=x86_64-pc-mingw32
No working C compiler found.

The crulpit seems to be the cross-prefix, as setting the host works, but obviously throws a whole bunch of other error messages when running make, as it cannot find the appropriate tools without the cross-prefix.

Compiling for x86 works just fine though.

Any ideas?

[outlaw78]

carefull :

use ./configure --cross-prefix=x86_64-pc-mingw32-
not ./configure --cross-prefix=x86_64-pc-mingw32

[eViLsTieFel]

Oh okay, thanks for that. Seems I actually didn't follow it to the letter… this happens when you for ONE time don't copy&paste but type it yourself.
Works like a charm now.

[r4dius]

Hi guys,

Can someone point out why is official x264 6MB large ?
I'm getting a 1MB exe when compiling it myself.

Thanks

[RiCON]

Because you're probably compiling it without FFMS2 support.

[r4dius]

Ahah that's right, my bad