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!

[shroomM]

OK, thanks for the answer, I'll dive a bit deeper and see how far I get :)

[rack04]

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?

You're doing something wrong because x264_win_zone_parse_fix_06.diff patches the latest git just fine.

[LoRd_MuldeR]

Maybe a borked patch.exe? I had a similar problem a while back, after I had updated my MSYS :rolleyes:

shroomM, maybe try that one:
http://www.mediafire.com/file/yhedc5njwnn/patch-ca5c3b07f60ebd6ea10eacf5fd9592ee.zip

[shroomM]

Yup, that helped, at least for the x264_win_zone_parse_fix_06.diff, I'll try the nal-hrd later.

Thank you both for your answers!

A.

[Snake91]

Hi, I downloaded komisar gcc, pthread and msys (I'm not interested in mp4 output so no gpac), when I compile x86 build all went fine, when I set --cross-prefix="x86_64-pc-mingw32" the shell says "No working C compiler found". What am i doing wrong?

[LoRd_MuldeR]

try --cross-prefix="x86_64-pc-mingw32-" ;)

[Snake91]

Thanks! I was becoming mad:devil:

[XhmikosR]

I'm having trouble in building the 64bit version of x264. I'm using komisar's gccc 4.4.2. I use:
./configure --extra-cflags="-march=core2" --host=x86_64-pc-mingw32 --cross-prefix=x86_64-pc-mingw32-

When I use make I get the following:

http://pastie.org/private/p1en496w2dkewno8d69d5q

It seems that ld.exe from i686-pc-mingw32 folder gets used, despite the fact that I have specified --cross-prefix=x86_64-pc-mingw32-.

BTW, I tried to compile pthread for 64bit using this patch (http://komisar.gin.by/x.patch/pthreads64.diff) but it doesn't apply as it should.

xmr@XMR-PC /desktop/pthreads-w32-2-8-0-release
$ patch -p0 -i pthreads64.diff
patching file GNUmakefile
patching file Makefile
Hunk #1 FAILED at 27.
1 out of 2 hunks FAILED -- saving rejects to file Makefile.rej
patching file config.h
patching file create.c
patching file implement.h
patching file pthread.h
patching file pthread_cancel.c
Hunk #1 succeeded at 74 (offset 27 lines).
patching file ptw32_InterlockedCompareExchange.c
Hunk #1 succeeded at 132 (offset -2 lines).
patching file ptw32_MCS_lock.c

[komisar]

I'm having trouble in building the 64bit version of x264. I'm using komisar's gccc 4.4.2. I use:
./configure --extra-cflags="-march=core2" --host=x86_64-pc-mingw32 --cross-prefix=x86_64-pc-mingw32-

When I use make I get the following:

http://pastie.org/private/p1en496w2dkewno8d69d5q

It seems that ld.exe from i686-pc-mingw32 folder gets used, despite the fact that I have specified --cross-prefix=x86_64-pc-mingw32-.
try "make clean" before configure

BTW, I tried to compile pthread for 64bit using this patch (http://komisar.gin.by/x.patch/pthreads64.diff) but it doesn't apply as it should.
this patch for 2-9-0-0
I pm you cvs command...

[XhmikosR]

I always make clean before configure. I even downloaded the source again but the message is still the same.

About pthreads64, isn't there any patch to work with version 2.8.0.0?

[komisar]

XhmikosR, try manual apply patch for pthreads

[XhmikosR]

OK, if I apply it manually everything is fine. But I still cannot understand why applying the patch fails if I use patch -p0 -i pthreads64.diff.
Any thoughts about this (http://forum.doom9.org/showpost.php?p=1340921&postcount=58) error I'm getting? If the ./configure command is right for building the x64 build of x264 then why am I getting that error?

[LoRd_MuldeR]

As komisar already pointed out, the patch is for pthreads 2.9.0 (CVS). You obviously tried to apply it to the 2.8.0 release version.

If the code that the patch modifies changed between 2.8.0 and 2.9.0, which obviously is the case, then the patch won't apply to that older version.

At least not without modification.

About your "ld.exe" error: Even if the ./configure script ran through correctly, there still may be something wrong with your MinGW environment.

[XhmikosR]

No, I downloaded the CVS version of pthreads.
"Something wrong with my MinGW environment". Something more specific in order to solve it? If I'm not wrong I'm using the same MiNGW version as you do, and I haven't modified anything in my MinGW folder except that I added libgpac and pthreads.

[LoRd_MuldeR]

Not sure ^^

But as far as I understand, the "x86_64-pc-mingw32-XXX.exe" files in "mingw\bin" will simply call to the actual binaries in "mingw\x86_64-pc-mingw32\bin\XXX.exe". Or they are copies of them, can't check now ;)

So if your build script (or Make) calls to "mingw\bin\x86_64-pc-mingw32-ld.exe", but obviously gets the 32-Bit version from "mingw\i686-pc-mingw32\bin\ld.exe", then something must be borked :scared:

Komisar offers several MinGW packages. At least v4.4.2 and v4.3.3 and both as "generic" and "core2". So maybe you simply try one of the other packages and see if that makes any difference to the problem...

[XhmikosR]

I know something is broken but since I have not changed anything and the configure command is correct then it's obviously something wrong not in my side. I'm using komisar's 4.4.2 generic build. And the same happened with his 4.4.1 generic. I'll try komisar's 4.4.2 core2 build.

EDIT: the same error with komisar's 4.4.2 core2.

[LoRd_MuldeR]

Now you should find out which of the possible "ld.exe" files is actually called. Maybe by renaming all but one to .off ;)

There should be "ld.exe", "x86_64-pc-mingw32-ld.exe" and "i686-pc-mingw32-ld.exe" in your "mingw\bin" folder. And more "ld.exe" files in "mingw\x86_64-pc-mingw32\bin" respectively "mingw\i686-pc-mingw32\bin".

Hopefully this will get us closer to the source of the problem...

[XhmikosR]

The one in "C:\mingw.442\i686-pc-mingw32\bin" folder is called. If I delete that (or rename it) then the one in "C:\mingw.442\bin" gets called but gives the same error. If I delete or rename that "ld.exe" too, I get "no working C compiler found" when running ./configure.

[komisar]

XhmikosR, in you compile-log present calling gcc, NOT x86_64-pc-mingw32-gcc... But configure seems correct. Post you "config.mak" after configure...

[XhmikosR]

Here it is.

prefix=/usr/local
exec_prefix=${prefix}
bindir=${exec_prefix}/bin
libdir=${exec_prefix}/lib
includedir=${prefix}/include
ARCH=X86_64
SYS=MINGW
CC=gcc
CFLAGS=-O4 -ffast-math -Wall -I. -march=core2 -DHAVE_MMX -DARCH_X86_64 -DSYS_MINGW -DPTW32_STATIC_LIB -DHAVE_PTHREAD -s -fomit-frame-pointer
ALTIVECFLAGS=
LDFLAGS= -lpthreadGC2 -lwsock32 -lgpac_static -lwinmm -lvfw32 -s
AR=x86_64-pc-mingw32-ar
RANLIB=x86_64-pc-mingw32-ranlib
STRIP=x86_64-pc-mingw32-strip
AS=yasm
ASFLAGS= -f win32 -m amd64 -DPREFIX
EXE=.exe
VIS=no
HAVE_GETOPT_LONG=1
DEVNULL=NUL

[komisar]

XhmikosR, CC=gcc? You mingw environment improper configured...
...and for x86_64-pc-mingw32 LDFLAGS must include "-lavifil32", not "-lvfw32"...

[XhmikosR]

That's a windows environment variable. How can I remove it from MSYS PATH only?

[komisar]

In "/etc/profile" changeif [ $MSYSTEM == MINGW32 ]; then
export PATH=".:/usr/local/bin:/mingw/bin:/mingw/lib:/bin"
else
export PATH=".:/usr/local/bin:/bin:/mingw/bin:/mingw/lib"
fi
Also, are you use sh.exe as shell, or windows cmd.exe?

[XhmikosR]

I don't know. I run it from it's shortcut on the desktop, so as a shell??

Can I permanently edit my MSYS PATH? Or do I have to use every time export PATH?

By the way, what you suggested didn't fix it. I still see CC=gcc in config.mak. Only by deleting the windows environment variable CC fixed it.

EDIT: make now works but when I run make fprofiled I get this (http://pastie.org/private/iuunl55sirrvec9es9704q).

[komisar]

XhmikosR, at first, read this documents for proper configure you mingw environment:
http://www.mingw.org/wiki/MSYS
http://www.mingw.org/wiki/Getting_Started

(Better use this MSYS: http://www.cadforte.com/msys.html )

After this you may replace "standart" MINGW with my build.

[khongminh]

I am a new babie. I try to complie x264 in linux like this:
1. ./config --disable-asm
2. make
3. make install
(I just download x264 version 2009-11-03 and compile it)
after that I run x264:
x264 -o image_out blue_sky.yuv 1920x1080
the result is:

x264 [info]: 1920x1080 @ 25.00 fps
x264 [info]: using cpu capabilities: none!
x264 [info]: profile High, level 4.0
x264 [info]: frame I:1 Avg QP:23.62 size:129268
x264 [info]: frame P:121 Avg QP:23.62 size: 57495
x264 [info]: frame B:95 Avg QP:27.57 size: 7997
x264 [info]: consecutive B-frames: 15.3% 75.0% 9.7% 0.0%
x264 [info]: mb I I16..4: 35.0% 44.6% 20.4%
x264 [info]: mb P I16..4: 1.6% 1.4% 0.3% P16..4: 38.5% 18.0% 14.6% 0.0% 0.0% skip:25.5%
x264 [info]: mb B I16..4: 0.1% 0.2% 0.0% B16..8: 45.9% 0.4% 0.4% direct: 0.9% skip:52.1% L0:31.7% L1:60.3% BI: 8.0%
x264 [info]: 8x8 transform intra:44.2% inter:64.4%
x264 [info]: coded y,uvDC,uvAC intra: 35.7% 48.2% 31.8% inter: 21.2% 33.2% 17.5%
x264 [info]: i16 v,h,dc,p: 53% 25% 12% 9%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 21% 9% 42% 4% 6% 4% 7% 3% 5%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 12% 16% 5% 14% 6% 15% 4% 6%
x264 [info]: ref P L0: 91.4% 5.5% 3.2%
x264 [info]: ref B L0: 96.3% 3.7%
x264 [info]: kb/s:7231.25

encoded 217 frames, 0.36 fps, 7231.25 kb/s
size of output is about 7MB. I can not run with VLC.

are There any problem? please help me. Thank you so much

[linyx]

@khongminh
Why would you disable assembly???:confused:
That slows down the encoding a fair amount in most every case.

[khongminh]

@khongminh
Why would you disable assembly???:confused:
That slows down the encoding a fair amount in most every case.
I am not familiar with linux, so I don't know how to configure YASM. Can you explain to me how to do it?

when I use ./configure --disable-asm
[root@localhost x264]# ./configure --disable-asm
./version.sh: line 2: git: command not found
Platform: X86
System: LINUX
asm: no
avis input: no
mp4 output: no
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no

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

if I just use ./confugre:

[root@localhost x264]# ./configure
Found no assembler
Minimum version is yasm-0.6.2
If you really want to compile without asm, configure with --disable-asm.

now, what do I do ?

[J_Darnley]

Install yasm 0.6.2 or newer. If you don't have that in that magical linux package manager, build it from source. ./configure && make && make install should do it.

[khongminh]

Install yasm 0.6.2 or newer. If you don't have that in that magical linux package manager, build it from source. ./configure && make && make install should do it.

I installed yasm 0.7.0 like this:

download yasm-0.7.0.tar.gz from http://www.tortall.net/projects/yasm/releases/
copy to /usr/
tar xvfz yasm-0.7.0.tar.gz
cd yasm-0.7.0
./configure
make
make install

after all I work with x264

[root@localhost x264]# ./configure
Found GNU assembler 2.15.94.0.2.2 20041220
Minimum version is binutils-2.17
Your compiler can't handle inline SSSE3 asm.
If you really want to compile without asm, configure with --disable-asm.

[root@localhost x264]# make
Makefile:3: config.mak: No such file or directory
grep: config.h: No such file or directory
./configure
Found GNU assembler 2.15.94.0.2.2 20041220
Minimum version is binutils-2.17
Your compiler can't handle inline SSSE3 asm.
If you really want to compile without asm, configure with --disable-asm.
make: *** [config.mak] Error 1

[root@localhost x264]# make install
Makefile:3: config.mak: No such file or directory
grep: config.h: No such file or directory
./configure
Found GNU assembler 2.15.94.0.2.2 20041220
Minimum version is binutils-2.17
Your compiler can't handle inline SSSE3 asm.
If you really want to compile without asm, configure with --disable-asm.
make: *** [config.mak] Error 1

I don't know how to fix it. What are problems, please tell me :confused:

[J_Darnley]

Upgrade your binutils to 2.17 or newer, as indicated by the error message. I think you need to hope that is in your package manager because I expect that won't be simple to compile from source. Another option would be to upgrade your from distro if it insists on giving you ancient tools.

[khongminh]

Upgrade your binutils to 2.17 or newer, as indicated by the error message. I think you need to hope that is in your package manager because I expect that won't be simple to compile from source. Another option would be to upgrade your from distro if it insists on giving you ancient tools.

Thank you for help. I upgraded binutils 2.17 version. and installed package git-1.6.0.tar.gz
when I run ./configure
[root@localhost x264]# ./configure
Platform: X86
System: LINUX
asm: yes
avis input: no
mp4 output: no
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no
You can run 'make' or 'make fprofiled' now.

and then I run make command

ranlib libx264.a
gcc -o x264 x264.o input/yuv.o input/y4m.o output/raw.o output/matroska.o output/matroska_ebml.o input/thread.o libx264.a -lm -lpthread -s
make: warning: Clock skew detected. Your build may be incomplete.


What is it? How can I fix it?

[LoRd_MuldeR]

http://www.linuxforums.org/forum/installation/3809-clock-skew-detected-your-build-may-incomplete.html

[khongminh]

http://www.linuxforums.org/forum/installation/3809-clock-skew-detected-your-build-may-incomplete.html
Thank you so much.
I'm using VMware to run linux and work with share folder. So It made skew error. Now I move all works to inside linux. It works well.
:thanks: