How to compile x264

[juGGaKNot]

K, i decided to give it a try

What would i need to install to get started ?
Where could i update the apps needed to compile ( GCC i guess )
Where would i get the updated versions when i want to update and rebuild ?
What would i need to read to understand how this works.

Any links of updated tutorials are welcomed.

Thnx, cheers.

[bnshrdr]

If you are on windows, you can compile through MSYS + MinGW. If you are on linux, naturally gcc.

Just the usual compile routine: ./configure , make, make install
If you are wanting to use avi synth scripts though, be sure to compile it with the --enable-avis flag configured.

You can download the source here: http://www.videolan.org/developers/x264.html
But I would recommend downloading the compiled versions created by people here in these forums. I think one of the sticky topics has daily builds, and if you haven't really had much experience compiling before, it might just be easier to let the people who do know how to do it. I'm not saying avoid compiling it yourself. There's nothing like learning a new trade.

[LoRd_MuldeR]

What would i need to install to get started ?

MSYS + MinGW/GCC + Git (+ YASM + pthreads + GPAC)

Where could i update the apps needed to compile ( GCC i guess )

MinGW Web-Site (http://mingw.sf.net/) -or- TDM's Web-Site (http://www.tdragon.net/recentgcc/)

Where would i get the updated versions when i want to update and rebuild ?

http://git.videolan.org/gitweb.cgi?p=x264.git

[Dark Shikari]

If you are on windows, you can compile through MSYS + MinGW. If you are on linux, naturally gcc.

Just the usual compile routine: ./configure , make, make install
If you are wanting to use avi synth scripts though, be sure to compile it with the --enable-avis flag configured.--enable-avis is on by default on platforms that support it.

[juGGaKNot]

Windows xp.

thnx.

i will give it a try now

[juGGaKNot]

Installed tdm-mingw-1.905.0-4.4.0-2 ( gcc-4.4.0-tdm, not 3.4.5 stable )
Got latest git

What now ?

[LoRd_MuldeR]

If you want Assembler enabled (otherwise x264 will be sloooow), you should also put "yasm.exe" into your "mingw\bin" folder. Also I recommend to get MSYS.

Then run MSYS, switch to the directory where you have checked out the x264 sources via Git, type "./configure", press Enter and see what happens ;)

[juGGaKNot]

hmm :) i will!

[unnikrisb4u]

Good Forum to help the newbies !!!

Today i compile ffmpeg for testing encoding and decoding h263 and h264.
I have used libx264 from videolan.

[elguaxo]

MSYS + MinGW/GCC + Git (+ YASM + pthreads + GPAC)



MinGW Web-Site (http://mingw.sf.net/) -or- TDM's Web-Site (http://www.tdragon.net/recentgcc/)



http://git.videolan.org/gitweb.cgi?p=x264.git

Great! I'm a complete n00b and the first steps were far easier than expected. :)

I used TDM's GCC/mingw32 Build and I haven't installed GPAC yet (no mp4 output), so I got this after ./configure

./version.sh: line 2: git: command not found
Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: no
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no

You can run 'make' or 'make fprofiled' now.

after my first make try I got an error saying that zlib was missing. I downloaded zlib-1.2.3-1-mingw32-src.tar.gz, extracted all to a new /zlib dir, then I switched to that directory with MSYS and used ./configure && make && make install. Is that enough?

Then after my next make try I got:
$ make
rm -f .depend
gcc -O4 -ffast-math -Wall -I. -march=i686 -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DH
AVE_PTHREAD -s -fomit-frame-pointer common/mc.c -MT common/mc.o -MM -g0 1>> .de
pend; gcc -O4 -ffast-math -Wall -I. -march=i686 -DHAVE_MMX -DARCH_X86 -DSYS_MI
NGW -DHAVE_PTHREAD -s -fomit-frame-pointer common/predict.c -MT common/predict.
o -MM -g0 1>> .depend; gcc -O4 -ffast-math -Wall -I. -march=i686 -DHAVE_MMX -D
ARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer common/pixel.c -MT
common/pixel.o -MM -g0 1>> .depend; gcc -O4 -ffast-math -Wall -I. -march=i686
-DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer common
/macroblock.c -MT common/macroblock.o -MM -g0 1>> .depend; gcc -O4 -ffast-math
-Wall -I. -march=i686 -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomi
t-frame-pointer common/frame.c -MT common/frame.o -MM -g0 1>> .depend; gcc -O4
-ffast-math -Wall -I. -march=i686 -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTH
READ -s -fomit-frame-pointer common/dct.c -MT common/dct.o -MM -g0 1>> .depend;
gcc -O4 -ffast-math -Wall -I. -march=i686 -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -
DHAVE_PTHREAD -s -fomit-frame-pointer common/cpu.c -MT common/cpu.o -MM -g0 1>>
.depend; gcc -O4 -ffast-math -Wall -I. -march=i686 -DHAVE_MMX -DARCH_X86 -DSY
S_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer common/cabac.c -MT common/cabac.
o -MM -g0 1>> .depend; gcc -O4 -ffast-math -Wall -I. -march=i686 -DHAVE_MMX -D
ARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer common/common.c -MT
common/common.o -MM -g0 1>> .depend; gcc -O4 -ffast-math -Wall -I. -march=i68
6 -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer comm
on/mdate.c -MT common/mdate.o -MM -g0 1>> .depend; gcc -O4 -ffast-math -Wall -
I. -march=i686 -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-
pointer common/set.c -MT common/set.o -MM -g0 1>> .depend; gcc -O4 -ffast-math
-Wall -I. -march=i686 -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fom
it-frame-pointer common/quant.c -MT common/quant.o -MM -g0 1>> .depend; gcc -O
4 -ffast-math -Wall -I. -march=i686 -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PT
HREAD -s -fomit-frame-pointer common/vlc.c -MT common/vlc.o -MM -g0 1>> .depend
; gcc -O4 -ffast-math -Wall -I. -march=i686 -DHAVE_MMX -DARCH_X86 -DSYS_MINGW
-DHAVE_PTHREAD -s -fomit-frame-pointer encoder/analyse.c -MT encoder/analyse.o
-MM -g0 1>> .depend; gcc -O4 -ffast-math -Wall -I. -march=i686 -DHAVE_MMX -DAR
CH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer encoder/me.c -MT enco
der/me.o -MM -g0 1>> .depend; gcc -O4 -ffast-math -Wall -I. -march=i686 -DHAVE
_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer encoder/rate
control.c -MT encoder/ratecontrol.o -MM -g0 1>> .depend; gcc -O4 -ffast-math -
Wall -I. -march=i686 -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-
frame-pointer encoder/set.c -MT encoder/set.o -MM -g0 1>> .depend; gcc -O4 -ff
ast-math -Wall -I. -march=i686 -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD
-s -fomit-frame-pointer encoder/macroblock.c -MT encoder/macroblock.o -MM -g0
1>> .depend; gcc -O4 -ffast-math -Wall -I. -march=i686 -DHAVE_MMX -DARCH_X86 -
DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer encoder/cabac.c -MT encoder/c
abac.o -MM -g0 1>> .depend; gcc -O4 -ffast-math -Wall -I. -march=i686 -DHAVE_M
MX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer encoder/cavlc.
c -MT encoder/cavlc.o -MM -g0 1>> .depend; gcc -O4 -ffast-math -Wall -I. -marc
h=i686 -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer
encoder/encoder.c -MT encoder/encoder.o -MM -g0 1>> .depend; gcc -O4 -ffast-ma
th -Wall -I. -march=i686 -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -f
omit-frame-pointer common/x86/mc-c.c -MT common/x86/mc-c.o -MM -g0 1>> .depend;
gcc -O4 -ffast-math -Wall -I. -march=i686 -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -
DHAVE_PTHREAD -s -fomit-frame-pointer common/x86/predict-c.c -MT common/x86/pre
dict-c.o -MM -g0 1>> .depend; gcc -O4 -ffast-math -Wall -I. -march=i686 -DHAVE
_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer x264.c -MT x
264.o -MM -g0 1>> .depend; gcc -O4 -ffast-math -Wall -I. -march=i686 -DHAVE_MM
X -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer matroska.c -MT
matroska.o -MM -g0 1>> .depend; gcc -O4 -ffast-math -Wall -I. -march=i686 -DHA
VE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD -s -fomit-frame-pointer muxers.c -
MT muxers.o -MM -g0 1>> .depend;
gcc -O4 -ffast-math -Wall -I. -march=i686 -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DH
AVE_PTHREAD -s -fomit-frame-pointer -c -o x264.o x264.c
In file included from common/common.h:649,
from x264.c:31:
common/macroblock.h: In function 'x264_mb_transform_8x8_allowed':
common/macroblock.h:465: warning: dereferencing type-punned pointer will break s
trict-aliasing rules
gcc -O4 -ffast-math -Wall -I. -march=i686 -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DH
AVE_PTHREAD -s -fomit-frame-pointer -c -o muxers.o muxers.c
In file included from common/common.h:649,
from muxers.c:24:
common/macroblock.h: In function 'x264_mb_transform_8x8_allowed':
common/macroblock.h:465: warning: dereferencing type-punned pointer will break s
trict-aliasing rules
muxers.c: In function 'read_frame_y4m':
muxers.c:293: warning: dereferencing type-punned pointer will break strict-alias
ing rules
gcc -O4 -ffast-math -Wall -I. -march=i686 -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DH
AVE_PTHREAD -s -fomit-frame-pointer -c -o encoder/set.o encoder/set.c
In file included from ./common/common.h:649,
from encoder/set.c:26:
./common/macroblock.h: In function 'x264_mb_transform_8x8_allowed':
./common/macroblock.h:465: warning: dereferencing type-punned pointer will break
strict-aliasing rules
ar rc libx264.a common/mc.o common/predict.o common/pixel.o common/macroblock.o
common/frame.o common/dct.o common/cpu.o common/cabac.o common/common.o common/m
date.o common/set.o common/quant.o common/vlc.o encoder/analyse.o encoder/me.o e
ncoder/ratecontrol.o encoder/set.o encoder/macroblock.o encoder/cabac.o encoder/
cavlc.o encoder/encoder.o common/x86/mc-c.o common/x86/predict-c.o common/x86/ca
bac-a.o common/x86/dct-a.o common/x86/deblock-a.o common/x86/mc-a.o common/x86/m
c-a2.o common/x86/pixel-a.o common/x86/predict-a.o common/x86/quant-a.o common/x
86/sad-a.o common/x86/cpu-a.o common/x86/dct-32.o common/x86/pixel-32.o
ranlib libx264.a
gcc -o x264.exe x264.o matroska.o muxers.o libx264.a -lpthread -lvfw32 -s
Is everything wrong?

Another problem is if I try a make fprofiled I get:
$ make fprofiled
usage: make fprofiled VIDS="infile1 infile2 ..."
where infiles are anything that x264 understands,
i.e. YUV with resolution in the filename, y4m, or avisynth.

Any hints? Thanks in advance!

[juGGaKNot]

first remove "bin\rxvt.exe" from mingw folder

install git

to test if installed type git and enter

to get latest x264

make a new dir, go to it ( cd /x/xxxx ) and type git clone git://git.videolan.org/x264.git x264-src

go to folder, /x/xxxx/x264-src and make fprofiled VIDS=/c/sample.avs if no errors

[LoRd_MuldeR]

@elguaxo:

1. It appears GIT is missing in your path! Add the GIT folder to your path like this, but adjust the path according to your local system:

export PATH="$PATH:/c/git/bin"

2. Make fprofiled needs a video file (uncompressed YUV file -or- Avisynth script) to work with. Try like this:

make fprofiled VIDS="soccer.avs"

[elguaxo]

First, I think the zlib error I got was related to GPAC. I'm not using it for now.

I started from scratch, the export PATH="$PATH:/c/git/bin" fixed the git: command not found during configure and adding an Avisynth script allowed me to do a make fprofiled! Now I have a working x264 :)

The next problem is pthreads. I got it from here (ftp://sourceware.org/pub/pthreads-win32/pthreads-w32-2-8-0-release.tar.gz). I followed these instructions (http://forum.doom9.org/showthread.php?p=1097709#post1097709), but my build still needs the "shared" pthreadGC2.dll. Any hints?

[LoRd_MuldeR]

The next problem is pthreads. I got it from here (ftp://sourceware.org/pub/pthreads-win32/pthreads-w32-2-8-0-release.tar.gz). I followed these instructions (http://forum.doom9.org/showthread.php?p=1097709#post1097709), but my build still needs the "shared" pthreadGC2.dll. Any hints?

I'm using TDM's MinGW GCC 4.4.0, which already ships with pthreads. However my only way to get x264 compiled with static linked pthreads is this:

Goto the "MinGW\lib" folder and remove all "libpthread*" files, except for the "libpthreadGC2-static.a" file. Also the latter should be renamed to "libpthread.a" ;)

Then re-run "./configure" and do a "make clean" plus "make (fprofiled)". Done.

[elguaxo]

Everything works now. :) Thanks LoRd_MuldeR!

edit: BTW deleting \MinGW\lib\libpthread*.a and renaming libpthreadGC2-static.a to libpthread.a didn't work for me, I got an x264 without pthreads at all. Deleting libpthread*.a and renaming libpthreadGC2-static.a to libpthreadGC2.a did the trick for me.

[rack04]

2. Make fprofiled needs a video file (uncompressed YUV file -or- Avisynth script) to work with. Try like this:

make fprofiled VIDS="soccer.avs"

Where can one obtain the video file need to make fprofiled work?

[LoRd_MuldeR]

Where can one obtain the video file need to make fprofiled work?

You can use whatever you want ;)

However I would use something that equals the kind of footage you are going to encode. Using "artificial" footage to profile x264 will probably not be beneficial.

Some of the popular uncompressed YUV clips can be found here:
* ftp://ftp.tnt.uni-hannover.de/pub/svc/testsequences/
* http://trace.kom.aau.dk/yuv/qcif.html
* http://trace.kom.aau.dk/yuv/cif.html

Also some uncompressed HD sequences here:
ftp://ftp.ldv.e-technik.tu-muenchen.de/dist/test_sequences/1080p/

[Dark Shikari]

Any footage will work, as long as it's real video footage. Junk data will not do the trick.

[rack04]

What advantage is it to fprofiled x264? Also, how do I configure -march=core2?

[LoRd_MuldeR]

What advantage is it to fprofiled x264?

It allows to C compiler to analyze the code while it's running and doing "real" work, which enables additional optimizations.

Also, how do I configure -march=core2?

./configure --extra-cflags="-march=core2"

[rack04]

If you want Assembler enabled (otherwise x264 will be sloooow), you should also put "yasm.exe" into your "mingw\bin" folder. Also I recommend to get MSYS.

Then run MSYS, switch to the directory where you have checked out the x264 sources via Git, type "./configure", press Enter and see what happens ;)

Do you have to configure the MinGW to use YASM or do you just place it in the bin folder?

[LoRd_MuldeR]

Do you have to configure the MinGW to use YASM or do you just place it in the bin folder?

Just place YASM.exe it in the MinGW\bin folder (in fact all you need to do is make sure it is in the PATH). Then the x264 configure script will do the rest ;)

[rack04]

Are these typical errors when fprofiled?

http://i11.photobucket.com/albums/a199/rack04/untitled3.jpg

[LoRd_MuldeR]

No, it's not "typical" for the linker to fail :eek:

[Dark Shikari]

No, it's not "typical" for the linker to fail :eek:Sure it is, if you don't have pthreads installed correctly.

[LoRd_MuldeR]

But then again it's not "typical" to have libraries missing that are needed for application you try to compile :p

Anyway, shouldn't the configure script disable pthreads if it isn't available?

[Dark Shikari]

But then again it's not "typical" to have libraries missing that are needed for application you try to compile :p

Anyway, shouldn't the configure script leave out libpthread if it isn't available?The configure script checks for pthread.h.

[LoRd_MuldeR]

If he has "pthread.h" but not "libpthread(GC2).a", then pthreads isn't installed properly. Rack04, make sure "libpthread(GC2).a" is located in your "mingw\lib" directory!

The pre-built files can be found here:
ftp://sourceware.org/pub/pthreads-win32/prebuilt-dll-2-8-0-release/lib/

If you want to link pthreads static, you can use the "libpthreadGC2-static.a" (rename to "libpthreadGC2.a") that ships with TDM's MinGW -or- build it yourself.

[juGGaKNot]

Any footage will work, as long as it's real video footage. Junk data will not do the trick.

make[1]: Leaving directory `/d/x264'
./x264.exe --crf 30 -b1 -m1 -r1 --me dia --no-cabac --direct temporal --ssim --n
o-weightb --threads 1 D:MSYS2_1184x666_40.yuv -o NUL ; ./x264.exe --crf 16 -b2
-m3 -r3 --me hex --no-8x8dct --direct spatial --no-dct-decimate -t0 --threads 1
D:MSYS2_1184x666_40.yuv -o NUL ; ./x264.exe --crf 26 -b4 -m5 -r2 --me hex --cqm
jvt --nr 100 --psnr --no-mixed-refs --b-adapt 2 --threads 1 D:MSYS2_1184x666_40
.yuv -o NUL ; ./x264.exe --crf 18 -b3 -m9 -r5 --me umh -t1 -A all --b-pyramid -
-direct auto --no-fast-pskip --threads 1 D:MSYS2_1184x666_40.yuv -o NUL ; ./x26
4.exe --crf 22 -b3 -m7 -r4 --me esa -t2 -A all --psy-rd 1.0:1.0 --threads 1 D:MS
YS2_1184x666_40.yuv -o NUL ; ./x264.exe --frames 50 --crf 24 -b3 -m10 -r3 --me
tesa -t2 --threads 1 D:MSYS2_1184x666_40.yuv -o NUL ; ./x264.exe --frames 50 -q
0 -m9 -r2 --me hex -Aall --threads 1 D:MSYS2_1184x666_40.yuv -o NUL ; ./x264.ex
e --frames 50 -q0 -m2 -r1 --me hex --no-cabac --threads 1 D:MSYS2_1184x666_40.yu
v -o NUL ;
x264 [info]: 1184x666 (given by file name) @ 25.00 fps
x264 [error]: could not open input file 'D:MSYS2_1184x666_40.yuv'
x264 [info]: 1184x666 (given by file name) @ 25.00 fps
x264 [error]: could not open input file 'D:MSYS2_1184x666_40.yuv'
x264 [info]: 1184x666 (given by file name) @ 25.00 fps
x264 [error]: could not open input file 'D:MSYS2_1184x666_40.yuv'
x264 [info]: 1184x666 (given by file name) @ 25.00 fps
x264 [error]: could not open input file 'D:MSYS2_1184x666_40.yuv'
x264 [info]: 1184x666 (given by file name) @ 25.00 fps
x264 [error]: could not open input file 'D:MSYS2_1184x666_40.yuv'
x264 [info]: 1184x666 (given by file name) @ 25.00 fps
x264 [error]: could not open input file 'D:MSYS2_1184x666_40.yuv'
x264 [info]: 1184x666 (given by file name) @ 25.00 fps
x264 [error]: could not open input file 'D:MSYS2_1184x666_40.yuv'
x264 [info]: 1184x666 (given by file name) @ 25.00 fps
x264 [error]: could not open input file 'D:MSYS2_1184x666_40.yuv'

Is this normal, the file exists.

[Kurtnoise]

make fprofiled VIDS="/d/MSYS2_1184x666_40.yuv"

[juGGaKNot]

make fprofiled VIDS="/d/MSYS/2_1184x666_40.yuv"

works, thnx, now have to get gpac binary and pthreads to work with 4.4.1 ( and read about optimizations )

cheers

[LoRd_MuldeR]

make fprofiled VIDS="/d/MSYS/2_1184x666_40.yuv"

works, thnx, now have to get gpac binary and pthreads to work with 4.4.1 ( and read about optimizations )

cheers

Given that you are using Komisar's build, you must copy the .a files to "i686-pc-mingw32\lib" and the .h files "i686-pc-mingw32\include".

Get pre-compiled GPAC here:
http://oss.netfarm.it/mplayer/pkgs/libgpac_static-mingw32-0.4.5-gcc45.tar.bz2

Pthreads, if you not already got it, is here:
ftp://sourceware.org/pub/pthreads-win32/prebuilt-dll-2-8-0-release/

(Note that after GPAC is installed, there should be the files "i686-pc-mingw32\include\gpac\isomedia.h" and so on in your MinGW directory)

[juGGaKNot]

"i686-pc-mingw32\include\gpac\isomedia.h" and so on in your MinGW directory)

all works, libgpac_static.a in lib with no rename.

k so what optimisations to use :) must read.

btw there also on the komisar cgg 4.4.1 page, just copy paste ( x64 version also there )

[LoRd_MuldeR]

all works, libgpac_static.a in lib with no rename.

k so what optimisations to use :) must read.

You don't need to use any additional optimizations, because x264 will already use -O4 -ffast-math by default. Which are the most aggressive optimizations of GCC ;)

Anyway, you may want to add --extrac-cflags="-march=core2" or --extrac-cflags="-march=amdfam10" depending on the type of CPU you intend your build to run on.

Last but not least you could use -floop-interchange -floop-strip-mine -floop-block to use the new "Graphite" Loop Transformations.

Not sure if that results in a faster binary in case of x264, but it shouldn't hurt either...

[juGGaKNot]

will see, for now generic is k

thnx

[komisar]

Last but not least you could use -floop-interchange -floop-strip-mine -floop-block to use the new "Graphite" Loop Transformations.
Not sure if that results in a faster binary in case of x264, but it shouldn't hurt either...
With fprofiling and "Graphite" binary is slower than only fprofiling (in my tests).
Only with "Graphite" (without fprofiling) sme as fprofiling in GCC434.
Good result for use "Graphite" -- gpac, pthread, ffmpeg (who dont use -fprofile-generate/use)

[LoRd_MuldeR]

With fprofiling and "Graphite" binary is slower than only fprofiling (in my tests).
Only with "Graphite" (without fprofiling) sme as fprofiling in GCC434.
Good result for use "Graphite" -- gpac, pthread, ffmpeg (who dont use -fprofile-generate/use)

Interesting...

[LoRd_MuldeR]

With fprofiling and "Graphite" binary is slower than only fprofiling (in my tests).
Only with "Graphite" (without fprofiling) sme as fprofiling in GCC434.
Good result for use "Graphite" -- gpac, pthread, ffmpeg (who dont use -fprofile-generate/use)

Did some more detailed test on my Q6600. Both builds are fprofiled. The "graphite" one additionally uses "floop-interchange", "-floop-strip-mine" and "-floop-block".

Results are here: http://pastebin.org/11739

Summary: With "veryslow" preset Graphite is slightly faster, with "veryfast" and at default settings it's a bit slower (but not too much).

Now I'm confused! Should I use it or not? :D

[lych_necross]

Did some more detailed test on my Q6600. Both builds are fprofiled. The "graphite" one additionally uses "floop-interchange", "-floop-strip-mine" and "-floop-block".

Results are here: http://pastebin.org/11739

Summary: With "veryslow" preset Graphite is slightly faster, with "veryfast" and at default settings it's a bit slower (but not too much).

Now I'm confused! Should I use it or not? :D
Does either preset affect stability? If not, I'd go with "veryslow" for the slight boost in speed. If all else fails, flip a coin :)

[komisar]

My speed tests for your brain... :)
Sequence of 5 iterations of each test on my "i7" (gcc 4.4.1) x86_64
options: --preset {prst} --quiet {asm} --no-progress -o nul SOCCER_352x288_30_orig_02.y4m

pf0: no fprofile; pf1: fprofile
gr0: without Graphite; gr1: with "-floop-interchange -floop-strip-mine -floop-block"
asm0: "--no-asm"; asm1: default asm
http://komisar.gin.by/test/speed1.png

[LoRd_MuldeR]

I think I'll drop Graphite. There's just no good reason to use it. Also there's no serious reason to drop it, but that doesn't matter. I'd need a reason to use it first ;)

@lych_necross: No, Graphite optimizations shouldn't effect "stability" at all. Unless there's a bug in GCC, the optimized version should give identical results...

[senseiam]

I am able to compile just fine BUT what would I need to change to compile a 64bit version?

[LoRd_MuldeR]

I am able to compile just fine BUT what would I need to change to compile a 64bit version?

Use the "x86_64-pc-mingw32" version of MinGW instead of the "i686-pc-mingw32" version.

Komisar's MinGW/GCC build includes both of them:
http://komisar.gin.by/mingw/index.html

I think you will also have to mess with the "--host" and "--cross-prefix" parameters ;)

[senseiam]

Use the "x86_64-pc-mingw32" version of MinGW instead of the "i686-pc-mingw32" version.

Komisar's MinGW/GCC build includes both of them:
http://komisar.gin.by/mingw/index.html

I think you will also have to mess with the "--host" and "--cross-prefix" parameters ;)

So something like:

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

should work?

[LoRd_MuldeR]

So something like:

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

should work?

I think you need:

$ ./configure --host="x86_64-pc-mingw32" --cross-prefix="x86_64-pc-mingw32-"

[senseiam]

I think you need:

$ ./configure --host="x86_64-pc-mingw32" --cross-prefix="x86_64-pc-mingw32-"

Thanks! :)

[Biggiesized]

May I ask what the purpose of compiling x264 yourself is?

[LoRd_MuldeR]

May I ask what the purpose of compiling x264 yourself is?

The x264 project only provides source code, no pre-compiled binaries! So somebody has to compile it, obviously ;)

Also many people include custom patches, enable CPU-specific compiler optimizations and/or use different compilers (or compiler versions) to make their x264 builds.

Furthermore x264 can be built for various platforms (Win32, Linux, etc.) and for different architectures (x86, AMD64, ARM, PowerPC).

Last but not least some people don't want to rely on others to provide up-to-date x264 builds now and then, so they prefer being able to build it themselves...

[shroomM]

I would also like to thank you all for great answers, I've successfully compiled the latest x264 build.

The question that I'm battling with now is, how to apply patches?

Well my question is not how to apply them per se (I know the command - patch -p1 < patch_name.diff, normally), but should the patches that are currently available (for example x264_hrd_pd_interlace.16_r1281.diff and x264_win_zone_parse_fix_06.diff) patch "out of the box" with the latest GIT version or do they require a lot of changing, fixing?

The reason I'm asking is that when I try to patch the GIT version with, for example, x264_win_zone_parse_fix_06.diff, all the hunks fail.

Is this normal, and manual changing is necessary or am I doing something wrong?

Regards,
A

[LoRd_MuldeR]

Well my question is not how to apply them per se (I know the command - patch -p1 < patch_name.diff, normally), but should the patches that are currently available (for example x264_hrd_pd_interlace.16_r1281.diff and x264_win_zone_parse_fix_06.diff) patch "out of the box" with the latest GIT version or do they require a lot of changing, fixing?

Patches are made against a specific revision. The patch may or may not work with a later revision. Often the patch needs to be adjusted by hand.

But even if the patch applies successfully to a later revision, there's absolutely no guarantee that the patch still works as intended with that revision!

Conclusion: Don't blindly apply any patches! You shouldn't apply a patch, unless you know what it does, how it works and why you need it...

The reason I'm asking is that when I try to patch the GIT version with, for example, x264_win_zone_parse_fix_06.diff, all the hunks fail.
Is this normal, and manual changing is necessary or am I doing something wrong?

Obviously that patch isn't compatibly with the latest GIT revision. If at least one "hunk" fails, you have a problem! So the patch needs to be updated.

Note that if a patch does apply with "fuzz", then this indicates a problem that could be fixed automatically. But better double-check in that case!