x264 compilation

[martino]

Progress indication patching doesn't really fail. If you inspect the patched x264.c you'll find out that the diff changes have been applied, however I'd like to know myself why it spits out "patch unexpectedly ends in middle of line".

[Sharktooth]

malformed patch file.
try deleting/adding the/a bottom blank line.

[Trahald]

pthreads comes in more than one version.. you have to compile the static library which will then link as part of x264.exe, not the dynamic (dll) version. see post 481

[gigah72]

patching with "patch -p1 < file.diff" works now, also linking with pthreads works now, i'm not shure if it was correct, but libpthread.a and libpthreadGC2.a is now the same file and the resulting exe works without the dll.
only question remains is about make fprofiled. i cut a scene in vdub, exporting it via ffdshow as uncompressed yv12 avi, but x264 doesn't recognize it. so what exactly do i need to do, to export this scene, that i can use it for fprofile or has someone a source for some free video that makes the job?

[Dark Shikari]

patching with "patch -p1 < file.diff" works now, also linking with pthreads works now, i'm not shure if it was correct, but libpthread.a and libpthreadGC2.a is now the same file and the resulting exe works without the dll.
only question remains is about make fprofiled. i cut a scene in vdub, exporting it via ffdshow as uncompressed yv12 avi, but x264 doesn't recognize it. so what exactly do i need to do, to export this scene, that i can use it for fprofile or has someone a source for some free video that makes the job?It needs a .yuv file--or on Windows, a .avs file.

[LoRd_MuldeR]

Try like this:
make fprofiled VIDS="/c/sample.avs"

BTW: What kind of video is recommended? Resolution? Length? etc... And why is my fprofiled DLL so much smaller? (721 vs. 575 KB)

[Dark Shikari]

Try like this:
make fprofiled VIDS="/c/sample.avs"

BTW: What kind of video is recommended? Resolution? Length? etc... And why is my fprofiled DLL so much smaller? (721 vs. 575 KB)Any ordinary video.

Profiled is smaller because it uses -Os on sections of code that are rarely run.

[LoRd_MuldeR]

Profiled is smaller because it uses -Os on sections of code that are rarely run.

:thanks:

[cacepi]

BTW: What kind of video is recommended? Resolution? Length? etc...
Resolution shouldn't matter much as don't need much information to generate the profile. A few hundred frames are plenty. (In fact, tests 6 & 8 for x264 only use 50 frames). I personally use test sequences:

http://meru.cecs.missouri.edu/free_download/videos/
http://www.w6rz.net/

[gigah72]

great, now fprofiled works, too. :)
but again, some questions:
OPT3 uses -t1, but i patched with psyrdo, so i get a warning. is this something that need to be changed in the makefile to -t0 or -t2, or leave it like it is?
and about optimization: i'm building "-march=k8", but on a coreduo, the k8 is my encoding/htpc and the coreduo my notebook. does this affect the resulting x264.exe in a negative way, e.g. not being fast as possible due to .... (technical stuff)?

[bob0r]

Any ordinary video.

Profiled is smaller because it uses -Os on sections of code that are rarely run.

My fprofiled builds are always bigger than normal builds.
"fprofiled is more information and thus bigger, thats what i thought, hmm"

[LoRd_MuldeR]

My fprofiled builds are always bigger than normal builds.
"fprofiled is more information and thus bigger, thats what i thought, hmm"

I don't think more information will be in the build. More information are collected/analyzed to optimize the build, at compile time.

My fprofiled "libx264.dll" is ~20% smaller than the normal one, using MinGW GCC 4.3.1-tdm-1 and the first 500 frames of the well-known "parkrun" video.

[LoRd_MuldeR]

I just compiled x264 r922 with PsyRDO patch (no B-Frames patch) as DLL, but it crashes on me:
http://www.avidemux.org/admForum/viewtopic.php?id=4945

x264 r920 did work okay for me. Any ideas? :confused:

:thanks:

[bob0r]

@LoRd_MuldeR

Can you try my .dll to confirm?
http://forum.doom9.org/showthread.php?p=1164668#post1164668

[LoRd_MuldeR]

@LoRd_MuldeR

Can you try my .dll to confirm?
http://forum.doom9.org/showthread.php?p=1164668#post1164668

I can't test that DLL with Avidemux, because it includes the "hrd_pulldown" patch, which changes the interface.
For current Avidemux I need either "Psy RDO" patch only, or you need to insert dummy fields for "i_psy_rd" and "f_psy_rd".
Also Gruntster's alignment fix patch is mandatory...

[bob0r]

libx264-60.928.test.01.dll (http://files.x264.nl/libx264-60.928.test.01.dll)

GIT 928 + psyrdo 0.5 patch (TEST ONLY)

configure --enable-shared
make

I see "Add missing x264util.asm", maybe that was the problem... please test :)

[Comatose]

Does fprofiled optimize the compile for a specific kind of video (the kind you give it)?

For example, will a x264 encode that was fprofiled with real life video produce lower quality anime encodes than one that was fprofiled with anime?
What exactly does it do? D:

[bob0r]

Lower quality: NEVER

fprofiled is to optimize for certain x264 options, speedwise.
It never has a negative effect.

[Shinigami-Sama]

Does fprofiled optimize the compile for a specific kind of video (the kind you give it)?

For example, will a x264 encode that was fprofiled with real life video produce lower quality anime encodes than one that was fprofiled with anime?
What exactly does it do? D:

its already been explained in this thread a couple times :P

it anaylizes the code as its running to see if it can figure out ways to make it faster
similar idea to just turning up -O#(s) w/e

[Comatose]

Well, this is a 26 page thread that I expect to be filled with the phrase fprofiled, so... :P

Anyway, thanks =)

[Sharktooth]

there is a "search this thread" function

[K0zi]

I'm trying to compile my own first x264 build using the guide from #166 (hpn) http://forum.doom9.org/showthread.php?p=723782#post723782
Step 18 runs into errors, no matter what versions of tools I use. I copied config.h from the gpac source folder to include/gpac/internal/config.h to work around the first one, but still, end up with this:
http://img6.imageshack.us/img6/2547/70594335.png

[skystrife]

You don't necessarily need a cvs gpac to do the muxing for x264--you could try building from one of the older snapshots on their main page and see if that works.

[Kurtnoise]

seems like compilation fails on Ubuntu 9.04 using the main branch...

ranlib libx264.a
gcc -o x264 x264.o matroska.o muxers.o libx264.a -lm -lpthread -s
libx264.a(ratecontrol.o): In function `init_pass2':
ratecontrol.c:(.text+0x1963): undefined reference to `isfinite'
ratecontrol.c:(.text+0x1bee): undefined reference to `isfinite'
libx264.a(ratecontrol.o): In function `rate_estimate_qscale':
ratecontrol.c:(.text+0x5d40): undefined reference to `isfinite'
ratecontrol.c:(.text+0x62f3): undefined reference to `isfinite'
collect2: ld a retourné 1 code d'état d'exécution
make: *** [x264] Erreur 1
lionel@ubuntu:~/x264$

$ uname -a
Linux ubuntu 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux

$ gcc -v
Utilisation des specs internes.
Target: i486-linux-gnu
Configuré avec: ../src/configure -v --with-pkgversion='Ubuntu 4.3.3-5ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Modèle de thread: posix
gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)


Quite strange though coz it worked last week :confused:...Any hint ?

[Henrikx]

Ubuntu 9.04
$ x264 --help
x264 core:67 r1145 d2e1e1c

De-Install libx264.dev

[Kurtnoise]

I don't use dev package for this compressor...

lionel@ubuntu:~$ find /usr/lib/ -name 'libx264*'
lionel@ubuntu:~$ find /usr/local/lib/ -name 'libx264*'

returns nothing...

[Henrikx]

HOWTO: Install and use the latest FFmpeg and x264
The instructions on the page are for Ubuntu Jaunty Jackalope 9.04

http://ubuntuforums.org/showthread.php?t=786095

[Kurtnoise]

useless for me...it was a conflict with a file header. Problem solved. :)

[LoRd_MuldeR]

I tried to compile x264 with MinGW 4.4.0, but configure fails:

./configure: line 320: die: command not found
Platform: X86
System: MINGW
asm: yes
avis input: no
mp4 output: no
pthread: no
debug: no
gprof: no
PIC: no
shared: yes
visualize: no

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

The line that fails is that one:

$CC $CFLAGS conftest.c -c -o conftest.o 2>$DEVNULL || die "endian test failed"

Any ideas? Did I miss something or is the compiler binary broken?

I used an "unofficial" MinGW build that I found here:
http://www.equation.com/servlet/equation.cmd?call=fortran

[kemuri-_9]

that's the first line something is actually compiled so the compiler is probably broken.

which is not surprising as i've been trying to compile 4.4.0 for mingw and it keeps failing as well.

[LoRd_MuldeR]

that's the first line something is actually compiled so the compiler is probably broken.

which is not surprising as i've been trying to compile 4.4.0 for mingw and it keeps failing as well.

Thanks for info :)

If you get your hands on a working MinGW 4.4.x binary, please let me know ;)

[Mr VacBob]

It's probably a compiler bug; you could take out the "2>$DEVNULL" to see what it prints before failing.

[LoRd_MuldeR]

It's probably a compiler bug; you could take out the "2>$DEVNULL" to see what it prints before failing.

Yeah, it says that the application caused the runtime to terminate in an "unusual" way.

[kemuri-_9]

Thanks for info :)

If you get your hands on a working MinGW 4.4.x binary, please let me know ;)

i got it working finally (at least enough to properly compile x264), but for x264 it's still slower than 3.4.x

on a note on this, due to how x264's configure writes values to TMP (in as_check() and cc_check())
this was crashing my gcc build as this does overwrite the temporary folder location (strangely is only affecting my gcc 4.4.0 x86/x64 builds)
as they were then trying to write to a nonexistent folder.
changing TMP to say TMPVAL and it works like a charm.
you should try this on the build you have, chances are it is the culprit on your side as well.

[LoRd_MuldeR]

on a note on this, due to how x264's configure writes values to TMP (in as_check() and cc_check())
this was crashing my gcc build as this does overwrite the temporary folder location (strangely is only affecting my gcc 4.4.0 x86/x64 builds)
as they were then trying to write to a nonexistent folder.
changing TMP to say TMPVAL and it works like a charm.
you should try this on the build you have, chances are it is the culprit on your side as well.

Hey thanks!

That solved the problem for me too, although I don't understand why renaming a variable in the bash script did fix the crash in GCC :)

In case anybody is interested, my patch is here:
http://mplayer.somestuff.org/misc/libx264/patches/configure-gcc440-fix.diff

Also I noticed that TDM finally has a MinGW 4.4.0 binary too:
http://www.tdragon.net/recentgcc/

BTW: GCC 4.4.0 is flooding the console with even more strange warning when compiling x264 than GCC 4.3.3 did :D

[kemuri-_9]

That solved the problem for me too, although I don't understand why renaming a variable in the bash script did fix the crash in GCC :)

BTW: GCC 4.4.0 is flooding the console with even more strange warning when compiling x264 than GCC 4.3.3 did :D

for the first part, it seems that GCC 4.4.0 is reading the TMP env variable for the location of the temporary folder for writing temp files.
x264's configure currently overwrites the location with the *_check() functions saving to the TMP variable.
so basically trying to save temporary files to a place that doesn't exist is naturally going to cause some failures.

I mentioned this in the dev channel, so it should probably get fixed along side with whatever the next commit will be.

i also noticed that gcc 4.4.0 was extremely angry at x264 with its mountain of "dereferencing pointer {} will break strict-aliasing rules" warnings.