x264 compilation

[max-holz]

Nasm, and some MSVC project management knowledge because iirc, the project doesn't build out of the box.

I have some little MSVC project management.
What must I include in the project?

Nasm and Gpac

There is a good guide, but it's for MinGW.

[bill_baroud]

there is nothing to "include", but you've to correct some path (like nasm for asm files because the vc7 conversion is b0rked). I remember modifying a some headers because it wasn't correct, but nothing major. It was some times ago (hmmm 17/05/2005) though...

[max-holz]

there is nothing to "include", but you've to correct some path (like nasm for asm files because the vc7 conversion is b0rked). I remember modifying a some headers because it wasn't correct, but nothing major. It was some times ago (hmmm 17/05/2005) though...

So GPAC must be compiled separately?

[leowai]

I got problem compiling rev425 using mingw (under windows) configured with "--enable-pic".

Following errors return from nasm (v0.98.39)
C:\xxx\x264\trunk>nasm -f win32 -DPREFIX -D__PIC__ -Icommon/i386/ -o common
/i386/dct-a.o common/i386/dct-a.asm
common/i386/dct-a.asm:164: error: symbol `..gotpc' undefined
common/i386/dct-a.asm:176: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:288: error: symbol `..gotpc' undefined
common/i386/dct-a.asm:307: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:402: error: symbol `..gotpc' undefined
common/i386/dct-a.asm:404: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:405: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:406: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:407: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:461: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:461: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:461: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:461: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:461: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:461: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:461: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:461: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:559: error: symbol `..gotpc' undefined
common/i386/dct-a.asm:561: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:562: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:563: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:564: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:613: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:613: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:613: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:613: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:613: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:613: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:613: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:613: error: symbol `..gotoff' undefined
common/i386/dct-a.asm:739: error: phase error detected at end of assembly.
Anyone experienced the same error?

BTW, how PIC works?

[celtic_druid]

Does PIC even work under windows? x264.exe uses a statically linked lib and x264vfw is a dll.

[leowai]

Does PIC even work under windows? x264.exe uses a statically linked lib and x264vfw is a dll.
Thanks. I see. My bad since PIC is not suppose to work under windows. :P

Compilation indeed works fine without PIC with MinGW.

Again. What's PIC that doesn't get supported under windows?

[foxyshadis]

PIC is how Apple and Unix do DLLs without fixups, basically. Their structure is much different from dlls and obviously windows can't use them.

[slavickas]

dunno myself for sure, but http://en.wikipedia.org/wiki/Position_independent_code sounds like it is

[leowai]

Thanks. I've better understanding of PIC now.

This shows why windows does not support PIC from the wikipedia:
-------------------------------------------------------------
Microsoft Windows DLLs are not shared libraries in the Unix sense and do not use position independent code. This means they cannot have their routines overridden by previously loaded DLLs and require small tricks for sharing selected global data. Code has to be relocated after it has been loaded from disk, making it potentially non-shareable between processes; sharing mostly occurs on disk.
-------------------------------------------------------------

[max-holz]

During compilation of gcc 4.0.2 I got this error

The directory that should contain system headers does not exist:
/usr/include
make[2]: *** [stmp-fixinc] Error 1
make[2]: Leaving directory `/c/gcc-4.0.2/obj/gcc'
make[1]: *** [stage1_build] Error 2
make[1]: Leaving directory `/c/gcc-4.0.2/obj/gcc'
make: *** [bootstrap] Error 2

I have unpacked source and created the dir C:\gcc-4.0.2 then I run this series of command under MinGW:

1. cd gcc-4.0.2/
2. mkdir obj
3: cd obj
4: ../configure --prefix=/usr/local
5: make CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap

perhaps I should have ran ../configure --srcdir=../gcc-4.0.2 --prefix=/usr/local
Anyone can help me?

[bob0r]

http://forum.doom9.org/showthread.php?p=724582

[max-holz]

http://forum.doom9.org/showthread.php?p=724582

But I haven't C\msys\1.0\local\include dir :(

[bob0r]

You dont use mingw?

Else just copy the local/include to whatever your root is (cd /)
So you have cd /include

I have:
/include/unistd.h
/include/wx-2.6/
/include/wx-2.6/wx/
/include/wx-2.6/wx/<headers here>

[max-holz]

Are there any problems in using gcc-4.0.2? I notice that most people use 3.4.5

[bob0r]

Are there any problems in using gcc-4.0.2? I notice that most people use 3.4.5

ffdshow won't compile with gcc 3.4.5
x264 make fprofiled won't compile with gcc 4.0.2

Thats what i have both gcc version compiled ready on my hdd (only have to make install to switch)

So uhm guess you could say gcc has some "problems" :D

[max-holz]

ffdshow won't compile with gcc 3.4.5
x264 make fprofiled won't compile with gcc 4.0.2

Thats what i have both gcc version compiled ready on my hdd (only have to make install to switch)

So uhm guess you could say gcc has some "problems" :D

Strange, I have compiled x264 fprofiled with 4.0.2 yesterday, many warnings but not error. Tested today the .mkv output and seems normal. You speak about ffdshow and I have question: can I compile it using only gcc and if yes where can I find a starting guide to understand how do it?

[bob0r]

http://forum.doom9.org/showthread.php?p=727041#post727041

The above is how i do it, but this is the latest script i use:
http://files.x264.nl/ffdshow/ffdshow_gcc.sh

[Oline 61]

Most everything I need works fine in gcc 4.0.2. That really only consists of x264 and mplayer though.

[DarkZell666]

Tried to compile x264 using VS.NET 2003.

I had to modify frame.h and common.h because of this stdint.h and inttypes.h business to correct 2 errors (thx omion, I had the same problem as Sirber)

But I still have the following (translated from french, so it might not be accurate :p) :

libx264 error PRJ0019: A tool returned an error code from "Assembly d:\x264-snapshot-20060213-2245\common\i386\predict-a.asm"

I'm surprised that VS blocks on this file when there are many others in alphabetical order before it ... and why does VS even try to compile it ?

Should I be using NASM or can VS compile x86 ASM but fails for another reason ?

[foxyshadis]

It's most likely a masm issue. I think I had to use masm from vs6 for virtualdub and x264 because of some subtle incompatibilities in memory access syntax with 2005, may be similar for 2003. You can rename the original, or just replace it.

The svn project file is also missing one or two of the asm files, since it was last updated who knows when. Just add in all the asm files and the missing ones will show up. Those need to be given the same build instructions as the others. In fact, it might just be this, and not masm at all.

[DarkZell666]

Hmm even if there is files missing, predict-a.asm only includes i386inc.asm and this file is present in the directory ... btw I've looked in the corresponding .svn/text-base dir and all the files are there with the same sizes so ... (I didn't connect to the svn I just grabbed a daily snapshot of the source, was it a bad idea ? It was x264-snapshot-20060213-2245)

As for masm I've searched a bit everywhere (starting with the .NET directories and vsnet2003 dir) and haven't found anything looking like it :)

I found it using google though :p and just saw that it wasn't supported by M$ anymore but by another brave guy =) So if I've understood, VS uses masm to compile the asm files, and it's (or should be) bundled with it somewhere (place that I can't find for now). And the recent versions of masm won't compile the x264 asm files because of subtil syntax differences ?
I would then need an older version (e.g. the one from VS6 you mentioned), but since I can't even find my executable I can't replace it :( What's it called ?

I don't have a clue where to start, all this linking/compiling stuff is too complicated for me with my actual skills (I can compile a VB/C# projet ok, but I haven't had to deal with advanced C++ projects yet ;)), maybe I'll just stick to the instructions given to do it with mingw (saw those a bit earlier in the thread).

[foxyshadis]

Masm's in the vs6 sp5 processor pack. Extract but don't install it. Just copy masm.exe into the 2003 C++/bin folder.

All the versions of vs past 6 should come with a masm in the c++/bin folder, but I'm not familiar with the 2003 environment specifically. Once you get past the 'omfg this thing keeps failing' it's actually very simple, just have to make sure all the files are included or you'll get the hated symbol not found in linking.

[celtic_druid]

In the past I have successfully compiled 32bit with MSVC 2003 using nasm and 64bit using yasm/MSVC 2005. You shouldn't need masm unless things have really changed.

[foxyshadis]

sorry, I meant nasm. >_< I'm so sorry, I've been working on a project that uses masm and I keep confusing the two.

[DarkZell666]

lool ok no problem, it's the sort of thing that just happens u know =)
At least I've learnt something ^^

Haven't tried to recompile since the other day, but I've had a hard time finding the processor pack so I just let go of the idea =)

[gumimaci]

Hi

I tried to patch the latest x264 (Rev.445) with Sharktooth's patches from http://files.x264.nl/Sharktooth/?dir=./x264_patches and it can't be.
Are there any newer patches?

[ChronoCross]

Hi

I tried to patch the latest x264 (Rev.445) with Sharktooth's patches from http://files.x264.nl/Sharktooth/?dir=./x264_patches and it can't be.
Are there any newer patches?

the patches need to be updated manually. Additionally not only do the lines have to be updated but there are portions of the code that have been updated since then to provide even greater speed and quality since then.

I have a build up that has all the patches applied. The only one I'm weary about is --subme 7 which needs some testing.

http://www.chronocrossdev.com/apps/x264/

[gumimaci]

Thanks, but that is a compiled x264.
I need the patched source.
Would you put it to your webspace if it's possible.

Thanks.

[ChronoCross]

Thanks, but that is a compiled x264.
I need the patched source.
Would you put it to your webspace if it's possible.

Thanks.

I'll only put it up if I can confirm it works. hopefully sirber is trying it out, if you want to try it out on a small clip say 45 seconds and see if --subme 7 works that'd be great. Then I'll put up the patched source.

[Sharktooth]

sirber said it doesnt work.

[ChronoCross]

okay then. well I looked at the functions that I changed and it's wierd that it throws compiling errors complaining about the arguements. So I tried changing the number of arguements and making it conform to the others in it but now that I know that doesn't work I need to investigate further as to why it's throwing erros on things that aren't changed by the patch.

[omion]

A bit of a minor weirdness: compiling r445 on XP x64 fails on predict-a.asm. It says "undefined symbol `FDEC_STRIDE' (first use)" even though it's in amd64inc.asm. I got around it by changing the custom build step command line to include "-D FDEC_STRIDE=32" but I figure there's a better way.

BTW, anybody know how much the recent cache coherency stuff helps?

[ChronoCross]

pengvado said there should be a 3-5% speed increase.

[Chainmax]

Do bob0r's compiles have all of Sharktooth's patches?

[Sharktooth]

no...

[max-holz]

I see that gcc-4.1.0 final is out. Any tricks how to compile x264 with make fprofiled without error?

[Sharktooth]

no... 4.1 is buggy and the gprofile bug is in WAIT state.

[squid_80]

A bit of a minor weirdness: compiling r445 on XP x64 fails on predict-a.asm. It says "undefined symbol `FDEC_STRIDE' (first use)" even though it's in amd64inc.asm. I got around it by changing the custom build step command line to include "-D FDEC_STRIDE=32" but I figure there's a better way.
Didn't we have to make another copy of amd64inc.asm and put it somewhere else, because yasm doesn't like a long command line?

[omion]

Didn't we have to make another copy of amd64inc.asm and put it somewhere else, because yasm doesn't like a long command line?
Oh yeah... I completely forgot about that. :D
I had no clue why that line wasn't working when the rest of the file clearly was. Now it all makes sense. Thanks!

[Chainmax]

no...

Do any compile besides yours have them?

[ChronoCross]

Do any compile besides yours have them?

I put up a few that had every patch cept --subme 7.

it's incompatible with the latest svn.

[Kostarum Rex Persia]

Who was worked on development of --subme 7 patch? Perhaps he can update subme 7 for new builds.

[ChronoCross]

Who was worked on development of --subme 7 patch? Perhaps he can update subme 7 for new builds.

pengvado(the author) already said no. he'll work on it again when it's time for it to be worked on again.

[Sharktooth]

The author is Alex_W though.

[Kostarum Rex Persia]

Ok, thanks guys. BTW, where is Alex_W, he didn't post on this forum some time.

[Sharktooth]

KRP: dont bug the devs for that. They already said "NO".

[Sirber]

Well, I'll have to keep an odler build :(.

@RealAnime users

Beware! Upgrading to recent x264 and using "High" quality profile will result in death! ;)

[ChronoCross]

The author is Alex_W though.
I think pengvado had made some of the more recent changes to the patch. I could be wrong though.

[ChronoCross]

Ok, thanks guys. BTW, where is Alex_W, he didn't post on this forum some time.

stay away from the dev's KRP.

[celtic_druid]

Well yeah kosaleksandar's last message on the dev list didn't go down to well.