How to compile x264 [Archive]

juGGaKNot

29th July 2009, 19:45

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

29th July 2009, 19:55

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

29th July 2009, 19:56

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

29th July 2009, 20:01

juGGaKNot

29th July 2009, 20:06

Windows xp.

thnx.

i will give it a try now

juGGaKNot

29th July 2009, 22:08

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

29th July 2009, 22:29

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

31st July 2009, 15:44

hmm :) i will!

unnikrisb4u

31st July 2009, 16:15

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

31st July 2009, 21:39

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

31st July 2009, 22:21

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

31st July 2009, 22:22

@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

1st August 2009, 01:49

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

1st August 2009, 01:58

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

1st August 2009, 03:04

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

2nd August 2009, 23:53

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

3rd August 2009, 00:05

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

3rd August 2009, 00:09

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

rack04

3rd August 2009, 00:24

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

LoRd_MuldeR

3rd August 2009, 00:26

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

3rd August 2009, 02:10

LoRd_MuldeR

3rd August 2009, 02:16

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

3rd August 2009, 04:03

Are these typical errors when fprofiled?

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

LoRd_MuldeR

3rd August 2009, 05:21

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

Dark Shikari

3rd August 2009, 05:24

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

LoRd_MuldeR

3rd August 2009, 05:40

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

3rd August 2009, 05:41

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

3rd August 2009, 05:46

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

5th August 2009, 10:25

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

5th August 2009, 10:53

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

juGGaKNot

5th August 2009, 11:08

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

5th August 2009, 13:01

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

5th August 2009, 14:34

"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

5th August 2009, 16:04

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

5th August 2009, 17:02

will see, for now generic is k

thnx

komisar

23rd August 2009, 19:00

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

23rd August 2009, 19:34

LoRd_MuldeR

24th August 2009, 22:44

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

25th August 2009, 08:17

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

25th August 2009, 12:45

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

25th August 2009, 14:43

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

8th September 2009, 07:11

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

LoRd_MuldeR

8th September 2009, 11:51

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

8th September 2009, 18:17

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

8th September 2009, 18:53

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

8th September 2009, 21:47

I think you need:

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

Thanks! :)

Biggiesized

5th October 2009, 00:01

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

LoRd_MuldeR

5th October 2009, 00:06

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

13th October 2009, 13:15

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

13th October 2009, 13:26

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

13th October 2009, 14:08

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

rack04

13th October 2009, 14:33

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

13th October 2009, 14:38

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

13th October 2009, 14:55

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

3rd November 2009, 21:43

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

3rd November 2009, 21:54

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

Snake91

3rd November 2009, 22:05

Thanks! I was becoming mad:devil:

XhmikosR

4th November 2009, 14:02

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

4th November 2009, 15:56

XhmikosR

4th November 2009, 16:11

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

4th November 2009, 16:42

XhmikosR, try manual apply patch for pthreads

XhmikosR

5th November 2009, 03:44

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

5th November 2009, 10:35

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

5th November 2009, 12:14

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

5th November 2009, 12:23

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

5th November 2009, 12:37

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

5th November 2009, 13:11

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

5th November 2009, 13:26

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

5th November 2009, 13:49

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

5th November 2009, 13:54

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

5th November 2009, 13:57

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

XhmikosR

5th November 2009, 13:59

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

komisar

5th November 2009, 14:03

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

5th November 2009, 14:22

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

5th November 2009, 16:55

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

25th November 2009, 03:49

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

25th November 2009, 04:43

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

khongminh

25th November 2009, 07:01

@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

25th November 2009, 12:20

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

25th November 2009, 14:12

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

25th November 2009, 14:34

khongminh

25th November 2009, 16:21

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

25th November 2009, 17:11

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

khongminh

26th November 2009, 02:06

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:

khongminh

16th December 2009, 10:44

I work on H264 and use MMX technology with PXA320 to improve speed of encoder. I write iwmmx_dct.asm file to make faster dct . and Compile this file like this:
/usr/local/arm-linux-4.1.1/bin/arm-iwmmxt-linux-gnueabi-as iwmmx_dct.asm
But it has error:
wmmx_dct.asm: Assembler messages:
iwmmx_dct.asm:0: Warning: end of file not at end of a line; newline inserted
iwmmx_dct.asm:1: Error: bad instruction `area iwmmx,CODE'
iwmmx_dct.asm:3: Error: bad instruction `global iwmmx_int_fdct4x4'
iwmmx_dct.asm:5: Error: bad instruction `iwmmx_int_fdct4x4 '
iwmmx_dct.asm:6: Error: selected processor does not support `wldrd wr0,[r0,#0x0*8]'
....

How can I fix that error. Thank you very much.

Dark Shikari

16th December 2009, 10:51

This has nothing to do with x264.

khongminh

16th December 2009, 19:16

This has nothing to do with x264.

But I use source x264. So it is really relative to X264. Please help me. I really need it

Dark Shikari

16th December 2009, 21:07

But I use source x264. So it is really relative to X264. Please help me. I really need itx264 does not contain any IWMMXT code.

khongminh

18th December 2009, 13:58

I built x264 on linux for pxa320 processor with the configure:
./configure --host=arm-linux --cross-prefix=/usr/local/arm-linux-4.1.1/bin/arm-linux-
and receive msg

You specified a pre-ARMv6 or Thumb-1 CPU in your CFLAGS.
If you really want to run on such a CPU, configure with --disable-asm.

and then "make" but it show some errors like:
input/yuv.c:24:20: error: muxers.h: No such file or directory
input/y4m.c:24:20: error: muxers.h: No such file or directory
output/raw.c:24:20: error: muxers.h: No such file or directory
output/matroska.c:21:20: error: muxers.h: No such file or directory
output/matroska_ebml.c:21:20: error: muxers.h: No such file or directory
output/flv.c:21:20: error: muxers.h: No such file or directory
output/flv_bytestream.c:24:27: error: common/common.h: No such file or directorymake: *** [.depend] Error 1
[root@localhost x264-snapshot-20091214-2245]#

Please tell me if i need some more configure and what to do for being able to use asm in this case

LoRd_MuldeR

18th December 2009, 17:41

Obviosuly some required x264 source files aren't found. Either you didn't checkout x264 completely or your search path is b0rked...

hyacinth

6th January 2010, 21:42

I am also working on compiling x264 on a linux machine, although I haven't compiled yet because I got a lot of 'no's from configure. I see that Dark Shikari had mentioned that some of these may be due to system support, but I had other questions about this. Is there anything I can install to get more 'yes's? For example, avs input? mp4 output? These seems like package dependencies, but I'm not sure. Also, I am assuming that if I compile with these as 'no', then I won't be able to run my normal win32 batch scripts with .avs files. Can I get these to work on Linux or should I go back to Win32?

Here's my current configure output:

$ ./configure
Platform: X86_64
System: LINUX
asm: yes
avs input: no
mp4 output: no
pthread: yes
debug: no
gprof: no
PIC: no
shared: no
visualize: no

Dark Shikari

6th January 2010, 21:46

mp4 output requires gpac.

avs input is Windows-only.

hyacinth

6th January 2010, 22:36

mp4 output requires gpac.

avs input is Windows-only.

Crap. I see that there was a project for Avisynth on Linux, but it looks rather... empty. I don't suppose there is a linux alternative to give you similar functionality? And without that, it would seem that encoding on linux is severely crippled. That's confounding. I guess it's back to Win32.

Dark Shikari

6th January 2010, 22:43

Crap. I see that there was a project for Avisynth on Linux, but it looks rather... empty. I don't suppose there is a linux alternative to give you similar functionality? And without that, it would seem that encoding on linux is severely crippled. That's confounding. I guess it's back to Win32.Option 1: Wine. Works great with avs2yuv.

Option 2: mplayer yuv4mpeg pipe.

Option 3: this (http://forum.doom9.org/showthread.php?t=151733).

hyacinth

6th January 2010, 23:27

Option 3: this (http://forum.doom9.org/showthread.php?t=151733).

Thanks. I think I'll look at this option. Along with other people wanting resize and crop functionality, I also use TDecimate functionality, so ultimately, my linux solution would need that, too.

Thanks again.

khongminh

25th January 2010, 17:55

I compile x264 by Visual Studio 2008. When I compile with x264-snapshot-20080706-2245 , it's okie, but it's updated to new one. I compile with newest version of x264. it error with asm file.
I can not understand why It happened.
dct-a.asm:199: error: operation size not specified
(pextrd [r0+FDEC_STRIDE*0], m0, 3)
and
common\x86\dct-64.asm:201: error: expression syntax error
(DCT_SUB8 sse2)
How can I fixed it.
Please Help Me, Thank You very much.

LoRd_MuldeR

25th January 2010, 19:56

x264 cannot be compiled by MSVC, at least not "as-is". There was a VS project file in the past, but it's not maintained in the official Git anymore.

All MSVC-specific code was removed in r1281. Therefore further modifications to the source code will be needed to make up-to-date x264 compile under MSVC.

So why not simply use MinGW/GCC, as everybody else does ???

Dark Shikari

25th January 2010, 19:57

roozhou

26th January 2010, 12:19

LoRd_MuldeR

6th April 2010, 21:55

So I updated my GCC 4.5.0 to the latest build (from 2010-03-27 to 2010-04-01) and suddenly x264 won't compile anymore:
http://pastie.org/906234

I get dozens of those errors in the linker phase:
x264.o:x264.c:(.text+0xc1): undefined reference to `__emutls_v.__gcov_indirect_call_counters'
x264.o:x264.c:(.text+0xd7): undefined reference to `__emutls_v.__gcov_indirect_call_callee'

GCC version info:
$ gcc -v
Using built-in specs.
COLLECT_GCC=d:\MinGW.450\bin\gcc.exe
COLLECT_LTO_WRAPPER=d:/mingw.450/bin/../libexec/gcc/i686-pc-mingw32/4.5.0/lto-wrapper.exe
Target: i686-pc-mingw32
Configured with: ../src/configure --prefix=/mingw_new --build=i686-pc-mingw32 --target=i686-pc-mingw32 --with-
sysroot=/mingw_new --with-build-sysroot=/mingw_new --with-libelf=/mingw_new/i686-pc-mingw32 --with-mpfr=/mingw
_new/i686-pc-mingw32 --with-gmp=/mingw_new/i686-pc-mingw32 --with-ppl=/mingw_new/i686-pc-mingw32 --with-cloog=
/mingw_new/i686-pc-mingw32 --with-mpc=/mingw_new/i686-pc-mingw32 --with-host-libstdcxx='-lstdc++ -lsupc++' --e
nable-static --enable-threads=win32 --enable-languages=c,c++,fortran,objc,obj-c++ --enable-version-specific-ru
ntime-libs --enable-fully-dynamic-string --enable-sjlj-exceptions --disable-shared --disable-rpath --disable-w
in32-registry --disable-bootstrap --disable-nls --with-gnu-ld --with-system-zlib
Thread model: win32
gcc version 4.5.0 20100331 (experimental) (GCC)

Any ideas? Is it simply GCC being broken? That's what I suspect, at least. Can anybody confirm ???

[EDIT]

Problem resolved: I updated GCC 4.5.0 again. Now I'm using the 2010-04-06 version and the problem disappeared :)

jamespand

19th September 2010, 18:04

Hi Friends,

I am new to video codecs.
I am using x264 msvc-2005 build.
My task is encode x264 to .mp4 , for that i downloaded gpac (gpac-0.4.5.rar) from sourceforge.
and downloaded zlib125-dll.zip for dependency of mp4Box.
Now i am getting error below...

Error 2 fatal error LNK1104: cannot open file 'js32.lib'
--------
can someone help me to fix it. Or advice me some code to plug in to x264 encoder. Please help me ASAP.

Thanks,
James

LoRd_MuldeR

19th September 2010, 18:14

So do you mean you have a pre-compiled "msvc-2005" binray of x264 or do you want to compile x264 yourself using MSVC ???

Anyway, x264 doesn't officially support MSVC as a compiler. It used to do so long ago, but support for MSVC was dropped in favor of MinGW/GCC.

If you wan to compile x264 yourself, why not use MinGW? And if you use pre-compiled x264, where did you get it?

LoRd_MuldeR

20th September 2010, 00:57

About link-time optimization

(1) Do I understand correctly that "-flto" must be passed to both, the compiler and the linker?

(2) Do I understand correctly that with LTO enabled, the optimization flags must be passed to the linker, as all the code generation now happens in the linker phase?

(3) If the above assumptions are correct, does this patch (http://pastie.org/private/rknrf1azgjueuoarsbmllg) make sense ???

Documentation:
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-flto-821

komisar

20th September 2010, 12:22

(1) yes.
(2) no. only if you need to change this flags in link-time.
(3) if you need -- pass extra flags in "--extra-cflags/--extra-ldflags"

for you attention:If object files containing GIMPLE bytecode are stored in a library archive, say libfoo.a, it is possible to extract and use them in an LTO link if you are using gold as the linker (which, in turn requires GCC to be configured with --enable-gold). To enable this feature, use the flag -fuse-linker-plugin at link-time:

gcc -o myprog -O2 -flto -fuse-linker-plugin a.o b.o -lfoo

With the linker plugin enabled, gold will extract the needed GIMPLE files from libfoo.a and pass them on to the running GCC to make them part of the aggregated GIMPLE image to be optimized.

If you are not using gold and/or do not specify -fuse-linker-plugin then the objects inside libfoo.a will be extracted and linked as usual, but they will not participate in the LTO optimization process.gold not available for mingw... the use of LTO is justified only for projects such as mp4box in gpac... but not for libgpac.a

p.s. gcc 4.5.x produce slower binary than gcc 4.4.x

LoRd_MuldeR

20th September 2010, 20:55

(2) no. only if you need to change this flags in link-time.

Are you 100% sure ???

As far as I understand, when compiled with LTO, then the object files will contain both, GIMPLE byetcode and the usual "final" code. The optimization flags passed at compile-time only apply to the "final" code generated at compile-time, but not to the GIMPLE bytecode. Also the docs say clearly that the flags passed at compile-time are not remembered in the GIMPLE code (with the only exception of "-fPIC", "-fcommon" and "-m"). Last but not least, when the object files are linked together with LTO enabled, then the linker will use the GIMPLE byetcode stored in the object files, if available. As the "final" code is then generated at link-time, the optimized flags that were passed at compile-time don't have any effect! Therefore I believe we must pass the optimization flags again at link-time when using LTO.

In my test with LTO enabled I noticed that when I used "-march" only at compile-time, but not at link-time, then all the binaries (i686, core2, amdfam10, pentium3) cam out at the identical byte-size. That made me suspicious! And another strange effect: The 'amdfam10' optimized build did not abort with "CLZ test failed: x264 has been miscompiled!" error on my Core2, which it usually (and for good reason) does! Then I re-read the GCC docs about LTO and I decided to pass the optimization flags (actually all the CFLAGS) also at link-time. And voilà! I got binaries of different size and the 'amdfam10' build errored out again.

So can you confirm this? Or what do I miss? :confused:

(3) if you need -- pass extra flags in "--extra-cflags/--extra-ldflags"

I'm aware of that method. But this way I had to "hard" pass all the optimization flags I'd like to have for the linker.

With the patch above, I can simply re-use that flags that the x264 ./configure added to the CFLAGS variable automatically, which I'd prefer.

komisar

20th September 2010, 22:04

can I put it wrong, but I mean something like `CF="-march=amdfam10 -O2"; configure --extra-cflags=$CF --extra-ldflags="-s $CF"`

LoRd_MuldeR

20th September 2010, 23:09

can I put it wrong, but I mean something like `CF="-march=amdfam10 -O2"; configure --extra-cflags=$CF --extra-ldflags="-s $CF"`

I think I got your point on this.

But this way I still would have to add all the optimization flags explicitly to the "--extra-ldflags" (or "CF", respectively), including those that x264 ./configure would normally add to CLFAGS automatically.

Any comments about the other issue?

jamespand

24th September 2010, 11:58

LoRd_MuldeR

24th September 2010, 20:46

@jamespand:
I moved you posts to the "Development" forum, as I think compilation issues better fit here.

You still didn't answer my previous questions: Why do you compile x264 in MSVC (not in MinGW/GCC) and what version of x264 are you using?

Up-to-date x264 doesn't ship with MSVC project files. Also the x264 code needs to be modified in order to satisfy MSVC. So did you pick an old version of x264, did you make the MSVC project files and the required code modifications yourself or are you using 'unofficial' project files and patches provided by someone else?

Adding MP4 support would be much easier with MinGW/MSYS, simply by using x264's "./configure" script. It will find and compile-in GPAC (MP4 output) automatically, if available.

jamespand

25th September 2010, 10:09

J_Darnley

25th September 2010, 10:30

Install gpac or apply the l-smash patch

LoRd_MuldeR

25th September 2010, 12:17

Hi,

I am using x264-snapshot-20090216-2245 and working fine as of now with msvc. now i want to made mp4 writer.

Thanks,
Pandu

Now that is a very old version! It works with MSVC because the support for MSVC was officially dropped around September 2009 ;)

I highly recommend to use an up-to-date x264 version, instead of such an old snapshot.

If one really needs to compile the latest x264 with MSVC, this is possible. It needs a few 'unofficial' code modifications and project files, but it works.

Anyway, you still haven't answered why you are insisting on MSVC, while the obvious way to compile x264 would be using MinGW/MSYS.

(And yes, it is possible to use a MinGW-compiled x264 DLL from a MSVC-compiled application - if that is your concern)

jamespand

25th September 2010, 12:59

Now that is a very old version! It works with MSVC because the support for MSVC was officially dropped around September 2009 ;)

I highly recommend to use an up-to-date x264 version, instead of such an old snapshot.

If one really needs to compile the latest x264 with MSVC, this is possible. It needs a few 'unofficial' code modifications and project files, but it works.

Anyway, you still haven't answered why you are insisting on MSVC, while the obvious way to compile x264 would be using MinGW/MSYS.

(And yes, it is possible to use a MinGW-compiled x264 DLL from a MSVC-compiled application - if that is your concern)

Thank you for reply, but my project is msvc based.
So i need to use msvc.

LoRd_MuldeR

25th September 2010, 13:49

Thank you for reply, but my project is msvc based.
So i need to use msvc.

No, as I already told you, you don't need to. You can built the libx264 DLL with MinGW/MSYS and still use it from an MSVC application.

Anyway, if your "project" uses x264 a library, then MP4 output cannot be "enabled" anyway, as the output modules (MKV, FLV, MP4, etc) are part of the x264 CLI encoder, and NOT part of the x264 library (libx264) itself. So if you want to use the output modules, you'd built the x264 CLI encoder as a "stand alone" application. And in that case there is even more reason to build it via MinGW/MSYS.

jamespand

25th September 2010, 14:07

No, as I already told you, you don't need to. You can built the libx264 DLL with MinGW/MSYS and still use it from an MSVC application.

Anyway, if your "project" uses x264 a library, then MP4 output cannot be "enabled" anyway, as the output modules (MKV, FLV, MP4, etc) are part of the x264 CLI encoder, and NOT part of the x264 library (libx264) itself. So if you want to use the output modules, you'd built the x264 CLI encoder as a "stand alone" application. And in that case there is even more reason to build it via MinGW/MSYS.

Ok,

Can you help me to install MinGW in windows7 PC.

LoRd_MuldeR

25th September 2010, 14:27

Can you help me to install MinGW in windows7 PC.

http://tinyurl.com/2epm45p

jamespand

25th September 2010, 15:59

No, as I already told you, you don't need to. You can built the libx264 DLL with MinGW/MSYS and still use it from an MSVC application.

Anyway, if your "project" uses x264 a library, then MP4 output cannot be "enabled" anyway, as the output modules (MKV, FLV, MP4, etc) are part of the x264 CLI encoder, and NOT part of the x264 library (libx264) itself. So if you want to use the output modules, you'd built the x264 CLI encoder as a "stand alone" application. And in that case there is even more reason to build it via MinGW/MSYS.

Hi,

any update on gpac compilation with msvc, because its giving zlib error.

LoRd_MuldeR

25th September 2010, 16:45

It's still unclear what you are doing. Did you move on to compiled x264 under MinGW/MSYS? If so, why are you still trying to compile GPAC under MSVC?

Under MinGW/MSYS you can simply grab Komisar's "Library pack for build x264", put the GPAC libs as well as the header files into their appropriate directories and run "./configure" form the x264 source directory.
http://komisar.gin.by/mingw/index.html

Anyway, if you need to compile GPAC yourself under MSVC for whatever reason and it complains about missing 'zlib', you'll need to compile the 'zlib' library first, I guess ;)

RBO

8th October 2010, 17:42

LoRd_MuldeR is right: GPAC needs zlib to compile ;)

GPAC also has troubles compiling with MinGW since I began working on 64 bits support. Because MinGW uses the runtime from VC6 (from 1998...).
Please use mingw64 for both 32 and 64 bits builds. I tried using more recent VC runtimes with MinGW as suggested on some forums, but the support seems unfortunately broken...

If you want to help or have tremendous problems compiling GPAC, please PM me or go to the GPAC forums. Thanks!

Romain

XhmikosR

8th October 2010, 18:39

@RBO:
http://xhmikosr.1f0.de/patches/gpac/gpac_mingw.patch
http://xhmikosr.1f0.de/patches/gpac/gpac_x64_mingw.patch

Both patches made by golgol7777. With the above patches I can successfully build the latest gpac svn with this (http://xhmikosr.1f0.de/tools/MSYS_MinGW_GCC_451_x86-x64_components.txt) toolchain.

RBO

11th October 2010, 14:48

Thank you :)

We officially don't support 64 bits platforms, but I take care of these patches until we finally make it (end of 2010 if ok ;) )