x264 compilation

[rushin_911]

@Sharktooth:

Could you please compile a P4 optimized build of revision 178 :), as it might be the last one for a long time?

[Sharktooth]

The P4 build is no faster than the standard SSE build and 178 wont be the last one.

[Sirber]

Originally posted by Sharktooth
178 wont be the last one. Good to hear :D Could you add to the sticky a small howto on how to compile it ourselve? I'm a noob in that field :(

[rushin_911]

Originally posted by Sharktooth
The P4 build is no faster than the standard SSE build and 178 wont be the last one.
oh ok well I'm glad to hear that :)

[Sharktooth]

Pretty easy sirber. No need to place it in the sticky.
Just grab mingw and all the stuff needed (msys, binutils, gcc ...).
Launch msys, move to the x264 dir then to build/cygwin/ and type "make NDEBUG=1".
From there move to ../../vfw/build/cygwin/ and do the same as above.
Move to bin and grab the dll.
That's compiled with default makefiles.

[Sirber]

Trying... got mingw, msys. Getting binutils and gcc. Do I put them in msys or mingw?

[Yong]

Originally posted by Sirber
Trying... got mingw, msys. Getting binutils and gcc. Do I put them in msys or mingw?
First, install Msys to directory "C:\Msys"(example),
then install mingw32 to "C:\Msys\Mingw32",
and you are done:)

[Sirber]

It says I need GCC :) binutils seems to be already included with mingw.

[edit]

sirber@DETRITUS-WS /x264/build/cygwin
$ make NDEBUG=1
C: common/mc.c
gcc.exe: no input files
make: *** [common/mc.obj] Error 1

sirber@DETRITUS-WS /x264/build/cygwin
$ gcc --help
gcc.exe: no input files

:confused:

[Yong]

Originally posted by Sirber
It says I need GCC :) binutils seems to be already included with mingw.

[edit]

sirber@DETRITUS-WS /x264/build/cygwin
$ make NDEBUG=1
C: common/mc.c
gcc.exe: no input files
make: *** [common/mc.obj] Error 1

sirber@DETRITUS-WS /x264/build/cygwin
$ gcc --help
gcc.exe: no input files

:confused:
Strange, compile x264 is pretty simple,
May be you can try to download the latest version binutil and put it into "C:\Msys\Mingw"....:)

[Sirber]

Latest binutils is older than mingw files :(

[Yong]

Originally posted by Sirber
Latest binutils is older than mingw files :(
binutils-2.15.94-20050118-1.tar.gz,
Are you sure?
What version of Mingw you use?
The "current" version i used seems create alot of problem,
may be the "Candidate" version is recommended:)

[Sirber]

MinGW-3.1.0-1.exe
MSYS-1.0.8.exe
binutils-2.13.90-20021006-2.tar.gz
gcc-3.2.3-20030504-1.tar.gz

I will try the "candidate".

[edit]

MSYS-1.0.8.exe
MinGW-3.2.0-rc-3.exe

Works! :D

[edit 2]

Now needing nasm :(

[dinolib2]

Just compiled latest sources with (in order of installation):

- MinGW-3.2.0-rc-3
- MSYS-1.0.10 (reply Y when ask to align with MinGW)
- nasm-0.98.39 (http://sourceforge.net/project/showfiles.php?group_id=6208&package_id=47034) (copy nasm.exe in /MinGW/bin)

That's all! :)

Look at x264.nl (http://mirror01.x264.nl/x264/readme.txt) for details

bye, Dino

edit: added link to nasm
edit2: msysDTK is not necessary (Sirber is right)

[Sirber]

I did not need msysDTK-1.0.1.

[Sirber]

I'd like to use: -O3 -march=athlon-xp -pipe -fomit-frame-pointer -mmmx -msse -m3dnow -mfpmath=sse -funroll-loops -msse2

but there are no ./configure and make don't like them. How? :(

[celtic_druid]

Edit the makefile adding -march=athlon-xp, etc.

[el divx]

Just tried to build it but when I go to "x264/build/cygwin", type "make" and then hit enter, it returns the following:

make: *** No rule to make target `common/mc.obj', needed by `libx264.a'. Stop.

Is it something related to the makefile?

[Magno]

May I ask why the decoder in x264 isn't working, even not compiling?

Just curiosity, because the coder has a built-in decoder to use the reconstructed samples as prediction to next decoded frames, so it only would be necessary to add code for CAVLC and CABAC decoding.

Anyone knows?

[LigH]

Not a complete answer, but a suspicion:

Due to the possible heavy use of (even rather wide, and multiple) forward and backward prediction, it is not easy to support VfW decoding of H.264 - just think of the "B-Frame lag" in XviD when using B-VOPs: Those AVIs either cannot be decoded sequentially, or have to be restructured (packed bitstreams).

So I guess: The AVI container appears to be one problem, and the VfW architecture another one.

DirectShow filters instead seem to be not bound to similar restrictions, they must have more "degrees of freedom" when decoding such heavily temporally depending material.

[Sirber]

Working! Added:ifdef AMD64
CFLAGS += -march=athlon-xp
CFLAGS += -mfpmath=sse
CFLAGS += -msse2
endif
make clean && make NDEBUG=1 AMD64=1

:D

[edit]

crashing! :D lol

ifdef AMD64
CFLAGS += -mmmx
CFLAGS += -msse
CFLAGS += -msse2
CFLAGS += -m3dnow
endif
Even this crash :confused: Standart build works though

[Sirber]

Remove:
CFLAGS += -ffast-mathAdd:
ifndef AMD64
CFLAGS += -ffast-math
endif
ifdef AMD64
CFLAGS += -march=athlon-xp
CFLAGS += -mfpmath=sse
CFLAGS += -mmmx
CFLAGS += -msse
CFLAGS += -msse2
CFLAGS += -m3dnow
endifmake NDEBUG=1 AMD64=1

[Sharktooth]

You can't use -ffast-math in conjuction with -mfpmath=sse or it will crash (gcc...).
Also don't try to add -fomit-frame-pointer or you will get screwed encodings.
Also use -march=athlon64.

[Sirber]

-march=athlon64

never saw that in GCC docs... gonna try :)

[Sharktooth]

Ensure you have gcc 3.4.x

[video]

Originally posted by Sirber
I'd like to use: -O3 -march=athlon-xp -pipe -fomit-frame-pointer -mmmx -msse -m3dnow -mfpmath=sse -funroll-loops -msse2

but there are no ./configure and make don't like them. How? :(

if you ar in a windows command enviroment, you may try this before configure:

set CFLAGS="-O3 -march=athlon-xp -pipe -fomit-frame-pointer -mmmx -msse -m3dnow -mfpmath=sse -funroll-loops -msse2"
set CXXFLAGS="-O3 -march=athlon-xp -pipe -fomit-frame-pointer -mmmx -msse -m3dnow -mfpmath=sse -funroll-loops -msse2"

[Sharktooth]

-fomit-frame-pointer = NO WAY.
Tried it and it produces artifacts.

-pipe = USELESS.
It's only for speed up the compiling process.

-msse2 = MAYBE but -march=athlon-xp? won't work on athlon xp CPUs...
I already built SSE2 binaries and even SSE3 but there was no significative speedup. The heavy parts are done in assembly so those flags wont make it faster...

[Sirber]

I didn't know there was a -march=athlon64, so I set athlon-xp. I'm doing this for fun and to learn, I don't aim public release.

[video]

Originally posted by Sharktooth
-fomit-frame-pointer = NO WAY.
Tried it and it produces artifacts.

-pipe = USELESS.
It's only for speed up the compiling process.

-msse2 = MAYBE but -march=athlon-xp? won't work on athlon xp CPUs...
I already built SSE2 binaries and even SSE3 but there was no significative speedup. The heavy parts are done in assembly so those flags wont make it faster...

Sharktooth You are right. I've just showed a trick how to tell configure to use specific compilation flags. I feel, anyway that using special flags don't help too much, 'coz critical parts already in asm. Remained c parts can be speed up, with a specific vectorizing compiler, I mean compiler what can do MIMD scheduling optimal for the processor's ROB - or alternatively rewrite some remained parts to asm or use BLAS.

Would like me to do a run on x264 with PathScale's EkoPath compiler? but EkoPath available only for linux.

[Sirber]

@video

Thanks for the hint, will be better than to mod the Makefile :D

[Sharktooth]

Originally posted by video
Sharktooth You are right. I've just showed a trick how to tell configure to use specific compilation flags. I feel, anyway that using special flags don't help too much, 'coz critical parts already in asm. Remained c parts can be speed up, with a specific vectorizing compiler, I mean compiler what can do MIMD scheduling optimal for the processor's ROB - or alternatively rewrite some remained parts to asm or use BLAS.

Would like me to do a run on x264 with PathScale's EkoPath compiler? but EkoPath available only for linux.
Well, i dont think it will be much faster. Btw, if you want to test it you're free to do it but usually x264 CLI is not of common use... mencoder is a much better solution.

[video]

Originally posted by Sharktooth
mencoder is a much better solution.
mencoder is reliant so much on a specific compiler and assembler. I feel it will be a pain in the ass to achieve compiling mplayer with ekopath, but i may try it :) However today x264's encoding quality is the major issue, not it's speed.

[Sharktooth]

It's incomplete... but it is the 2nd best AVC encoder after NeroDigital.

[video]

Originally posted by Sharktooth
It's incomplete... but it is the 2nd best AVC encoder after NeroDigital.

http://forum.hwsw.hu/html/emoticons/offtopic.gif I'm sorry, I didn't mean flaming on x264

[Sharktooth]

You didn't. I meant it's not the best encoder, but it has a relatively high quality even if it is incomplete.

[ChronoCross]

well I decided to compile the default version of the vfw. and the resulting dll was over 1000k when the same dll in the p3 version download of the mainpage is only about 450. what's up with that? I compiled it under cygwin using the makefile provided.

[dinolib2]

make NDEBUG=1
Compile x264 lib with this option

edit:completed answer

[Sharktooth]

The dll is now some kbytes smaller. It's barely 400kbytes (exactly 397kb for my SSE compile).

[Sirber]

Originally posted by Sharktooth
The dll is now some kbytes smaller. It's barely 400kbytes (exactly 397kb for my SSE compile). Optimization? :D UPX? :(

[Sharktooth]

UPX? no.
Maybe because some code has been rewritten.

[Sirber]

Mine is 1022KB :confused:
CFLAGS="-O3 -march=athlon64 -m32 -pipe -mfpmath=sse -funroll-loops"
CXXFLAGS="-O3 -march=athlon64 -m32 -pipe -mfpmath=sse -funroll-loops"
Same size whitout those flags

[dinolib2]

1200K is the size of the debug version...

I've already posted: try to compile with
make NDEBUG=1

does it solve your problem?

bye

[Sirber]

oh, forgot :D Thanks!

[Sharktooth]

I updated the install script to add the x.264 configuration link in the start menu.

[Sharktooth]

Installed commandline svn in my MSYS so my builds now show the svn version correctly (you can find it in the "about" box)

[Sharktooth]

Thanks! i was just going to ask to split the thread :D

EDIT: If you have any requests for my builds please post them here.

[bob0r]

I have used: ftp://sources.redhat.com/pub/pthreads-win32/pthreads-w32-2-6-0-release.exe

Did:
make clean GC-static

then:
copied libpthreadGC2.a > G:\MinGW\lib
copied pthread.h > G:\MinGW\include
copied sched.h > G:\MinGW\include

Now my make result is:

gcc -o x264.exe x264.o libx264.a -lvfw32 -lm4systems_static -lwinmm -lpthreadGC2 -s
libx264.a(encoder.o)(.text+0x394d):encoder.c: undefined reference to `_imp__pthread_create'
libx264.a(encoder.o)(.text+0x3982):encoder.c: undefined reference to `_imp__pthread_join'
collect2: ld returned 1 exit status
make: *** [x264.exe] Error 1

What have i done wrong?
Meaning, just explain me the full and correct way of handling this :(

[Sharktooth]

You have to place the pthreadGC2.dll in G:\MinGW\lib

EDIT: ehrr... not true. libpthreadGC2.a is enaugh.

[bob0r]

You have to place the pthreadGC2.dll in G:\MinGW\lib

Done that, still the same, i heard i have to "link it", how to?

[Sharktooth]

-L (uppercase) option

[bob0r]

-L (uppercase) option

Remember i have no idea what to do, you have to explain me what to do step by step

bob0r
:stupid:

All i know is:
cd x264
configure --enable-vfw --enable-avis-input --enable-mp4-output --enable-pthread
make clean
make

So i have no idea where and how to use -L