x264 compilation

[squid_80]

that is correct. each one has to have it's own id. so the overlapping id thing is a simple fix.
For the meantime why not give the experimental options high ids (e.g. 998, 999) so they don't need to be changed every time something new is added?

[akupenguin]

...and put them at the beginning of the list, so the patch's context doesn't break

[ChronoCross]

Sounds like a plan. I'll make a patch update for the next revision released.

[max-holz]

Today gpac's cvs update is borked? I have tried to compile with gcc-3.4.5 getting a couple of errors.


os_net.o:os_net.c:(.text+0x173): undefined reference to `getnameinfo'
os_net.o:os_net.c:(.text+0x49a): undefined reference to `getaddrinfo'
os_net.o:os_net.c:(.text+0x4d4): undefined reference to `freeaddrinfo'

[hpn]

rev.479 reduced the number of arguments to some function(s) used in x264_aq.5-xxx.diff, so the patch failed to compile. Hope akupenguin will post a fixed version of the patch when/if he finds time.

@max-holz
Nothing to worry about. Gpac's cvs is often broke, but usually gets fixed within a day or two. Just use some previous Gpac snapshot.

[ChronoCross]

rev.479 reduced the number of arguments to some function(s) used in x264_aq.5-xxx.diff, so the patch failed to compile. Hope akupenguin will post a fixed version of the patch when/if he finds time.

@max-holz
Nothing to worry about. Gpac's cvs is often broke, but usually gets fixed within a day or two. Just use some previous Gpac snapshot.

I need someone to test aq on this build. I think I understand what he changed. This is no way a perfect pathc but it MAY work.

WARNING: HIGHLY EXPERIMENTAL
http://chronocrossdev.com/apps/x264/479/x264.exe

I'll make another build once I know if this works....if it doesn't I'll release an official version without AQ.

[hpn]

@ChronoCross
rev.479 (vs. 478) only improves the encoding speed (plus 2k smaller .exe), so you could easily test if your new AQ patch is correct. Just make 2 AQ encodes with 478+old patch and 479+new patch and compare the encodes. It they are bit-identical your new AQ patch is (most likely) fine.

[ChronoCross]

unfortunately I don't have suitable test material available atm. which is why I asked lol

I updated the binary again, I screwed up the patch update. now it should be using the correct value.

[bob0r]

Gpac compiling is indeed broken:


ranlib ../bin/gcc/libgpac_static.a
gcc -shared -Wl,--warn-common -export-symbols libgpac.def -o ../bin/gcc/libgpac.dll *.o -lm -lws2_32 -lwinmm -lz
os_net.o(.text+0x173):os_net.c: undefined reference to `getnameinfo'
os_net.o(.text+0x49a):os_net.c: undefined reference to `getaddrinfo'
os_net.o(.text+0x4d4):os_net.c: undefined reference to `freeaddrinfo'
os_net.o(.text+0x1171):os_net.c: undefined reference to `getnameinfo'
os_net.o(.text+0x1205):os_net.c: undefined reference to `getaddrinfo'
os_net.o(.text+0x1221):os_net.c: undefined reference to `freeaddrinfo'
os_net.o(.text+0x1346):os_net.c: undefined reference to `getaddrinfo'
os_net.o(.text+0x1368):os_net.c: undefined reference to `freeaddrinfo'
make[1]: *** [libgpac.dll] Error 1
make[1]: Leaving directory `/home/user/gpac/src'
make: *** [lib] Error 2


But the required file for x264, libgpac_static.a, is working fine, so you can compile x264 just fine.
But indeed, gpac compiling and broken quite often, just report it and we can fall back on an older version, which is not needed now.
Thanks for the report!

[celtic_druid]

Problem is IPV6.

#ifdef IPV6_MULTICAST_IF
#pragma message("using WinSock IPV6")
#define GPAC_IPV6 1

Need to comment out
//#define GPAC_IPV6 1

Or I guess have the appropriate header files. Whatever they are. Either way IPV6 support is going to have zero effect on x264.

[max-holz]

Either way IPV6 support is going to have zero effect on x264.

Yes I saw, thanks celtic_druid

[emmel]

I already posted this in another thread, but its the header ws2tcpip.h of the newest mingw that seems to be broken:

#if (_WIN32_WINNT >= 0x0501)
void WSAAPI freeaddrinfo (struct addrinfo*);
blaablaa....
#else
/* FIXME: Need WS protocol-independent API helpers. */
#endif

[celtic_druid]

Really though if configure doesn't detect IPv6, then the code in question shouldn't be compiled.

[ChronoCross]

gpac update today fixes the problems from a few days ago. the libs compile fine now so update while you can.

[max-holz]

gpac update today fixes the problems from a few days ago. the libs compile fine now so update while you can.

I can't see any today's update in the cvs. Latest update for me is already borked. I have cancelled my gpac dir and done a cvs checkout. Then I recompile and the annoying problem with IPV6 is still there. ChronoCross are you drunk? :D


os_net.o(.text+0x173):os_net.c: undefined reference to `getnameinfo'
os_net.o(.text+0x49a):os_net.c: undefined reference to `getaddrinfo'
os_net.o(.text+0x4d4):os_net.c: undefined reference to `freeaddrinfo'
os_net.o(.text+0x1171):os_net.c: undefined reference to `getnameinfo'
os_net.o(.text+0x1205):os_net.c: undefined reference to `getaddrinfo'
os_net.o(.text+0x1221):os_net.c: undefined reference to `freeaddrinfo'
os_net.o(.text+0x1346):os_net.c: undefined reference to `getaddrinfo'
os_net.o(.text+0x1368):os_net.c: undefined reference to `freeaddrinfo'


P.S. If you aren't sure, browse the repository via HTTP and tell me which are the files updated.

[leowai]

Some here. Not new update check out so far since last nite.

Default cvs update setting will not give a clean update of gpac. Modified files will be merged in the in the cvs update process (default settings). ChronoCross did you have clean download of the gpac source?

[max-holz]

For Emmel

I have tried with a patched copy of ws2tcpip.h but still I get a couple of errors, I resaid that gpac is actually borked.

[ChronoCross]

it works fine for me in compilation of the lib files. they work fine with x264. i mean it throws alot of warnings but those should have no impact on the compilation. at least not for me anyway.

[lcx]

@max-holz

None of the functions in os_net.c are needed for x264.
You can just exclude it and any other files that use os_net from your build.

[max-holz]

@max-holz

None of the functions in os_net.c are needed for x264.
You can just exclude it and any other files that use os_net from your build.

Yes I know perfectly that I can patch os_net and I do it, but you can't exclude it from compilation even if IPV6 support is not detected from configure as celtic_druid said; this is another bug of the actually cvs. I could suppose that others include files not in the mingw package are needed.

[hellfred]

Hi there
I have checked gpac out today and build the libs and apps under debian linux (kanotix live dvd installed to hd). Just wanted to mention that after ./configure; make lib; make install-lib; make apps; make install
MP4Box did not find libgpac.so. The shared libary was compiled, but is not installed to /usr/local/lib. So I had to
install -m644 bin/gcc/libgpac.so /usr/local/lib/libgpac.so
chmod +x /usr/local/lib/libgpac.so
ldconfig
I am sure there are more elegant ways to get this done, but it worked out for me and might help others, too.

Hellfred

[max-holz]

Hi there
I have checked gpac out today and build the libs and apps under debian linux (kanotix live dvd installed to hd). Just wanted to mention that after ./configure; make lib; make install-lib; make apps; make install
MP4Box did not find libgpac.so. The shared libary was compiled, but is not installed to /usr/local/lib. So I had to
install -m644 bin/gcc/libgpac.so /usr/local/lib/libgpac.so
chmod +x /usr/local/lib/libgpac.so
ldconfig
I am sure there are more elegant ways to get this done, but it worked out for me and might help others, too.

Hellfred

Thanks hellfred, but the I'am speaking about it's probably a win32 compilation prob.

[hellfred]

Thanks hellfred, but the I'am speaking about it's probably a win32 compilation prob.You are right, this information will not help to workaround the bugs in the building process. But the topic of this thread in x264 compilation, gpac is needed for mp4 output and there is no restriction to win32. I just felt this piece of information might help another newbie to get the most out of his gpac compilation, that is mp4box for muxing the video stream from x264 together with some audio tracks. Just video and no sound is somewhat unsatifying :)

Hellfred

[lcx]

With command:
yasm -f win32 -DPREFIX -o dct-a.obj i386\dct-a.asm

I get the following errors:
dct-a.asm:272: label or instruction expected at start of line
dct-a.asm:272: label or instruction expected at start of line
dct-a.asm:280: label or instruction expected at start of line
dct-a.asm:280: label or instruction expected at start of line
dct-a.asm:287: label or instruction expected at start of line
dct-a.asm:288: label or instruction expected at start of line
dct-a.asm:289: label or instruction expected at start of line
dct-a.asm:290: label or instruction expected at start of line


Anyone know if I am doing something wrong or this is a bug in yasm?
I tried the latest yasm daily build with no luck.
Albeit, It does assemble in nasm.

[lcx]

Wow!
I reported the issue with yasm yesterday and this morning I wake up to find its fixed!
aku works extermely fast.

Thanks!

[lcx]

Changeset 504 libx264.dsp line 28

CPP=xicl6.exe


What compiler on windows is named xicl6 the default MSVC compiler is cl.exe ?

And whats up with the change to remove MP4 output from x264.vcproj?

[leowai]

And whats up with the change to remove MP4 output from x264.vcproj?
I think you need manually add in gpac library and some setup in order to get mp4 output supported. x264 project by it own do not support mp4 output.

[lcx]

OK I realize what is happening here.
The change must have come from omion.

He has a little weird way of compiling x264.
In addition, by default, gpac is somewhat broken on Win64 until you muck around with the gpac files -- so he must have removed gpac from the project.

[akupenguin]

The rationale given to me was:
gpac was assumed to be in "..\..\..\gpac\bin\w32_deb\libgpac_static.lib". This was a completely bogus path, and there was no good way to detect whether it exists, let alone search for gpac somewhere else.

Unless someone wants to write a .bat equivalent to the configure script, or however that's done...

[omion]

OK I realize what is happening here.
The change must have come from omion.

He has a little weird way of compiling x264.
In addition, by default, gpac is somewhat broken on Win64 until you muck around with the gpac files -- so he must have removed gpac from the project.
Wow, what a great theory! I don't compile my builds with GPAC, therefore I changed it so nobody else would either!

FYI, I had no say in the patch whatsoever. Nor does it look like somebody just took my version of the files and submitted them. I had nothing to do with this.

I don't know how you meant your post to be read, but it comes off very accusatory. Do you think you could have asked if I did it before you jump to your own conclusions? It's generally considered more civil than just blindly pointing fingers.

[squid_80]

I believe the include path for the gpac lib came from me, way back when the windows 64 stuff was imported. I keep x264 in l:\x264 and gpac in l:\gpac. I don't expect everyone to do the same, that's just how I had it set up and it ended up like that in x264's SVN. Now it's fixed.

There's nothing wrong with gpac on 64-bit either. At least, nothing more than the same problems it has on 32-bit.

[shin_san]

Hi all, I am a newbee and just need the x264 library to encode some parts of video in an existing vc++ project.

I use msvc 6 + sp6 + nasm + x264-snapshot-20060412-2245 and when I compile, I have 60 syntax errors with \encoder\rdo.c and some other with encoder\macroblock.c ... :(

May somebody help me?

[squid_80]

Maybe if you gave us a bit of a hint what the errors actually are.

[devaster]

by compiling in MSVS 2005 (latest platform,directx and windows media SDK) i get this error :
Error 1 error PRJ0019: A tool returned an error code from "Assembly ...\X264\trunk\common\i386\quant-a.asm"

what is this ??? :confused: :confused: :confused:

oh i forgot ... trying compile under XP x64 edition for debug x32 architecture ...

[lcx]

by compiling in MSVS 2005 (latest platform,directx and windows media SDK) i get this error :
Error 1 error PRJ0019: A tool returned an error code from "Assembly ...\X264\trunk\common\i386\quant-a.asm"

what is this ??? :confused: :confused: :confused:

oh i forgot ... trying compile under XP x64 edition for debug x32 architecture ...

Do you have yasm (or nasm) installed ?
If so, What error message does executing the following from the cmd-line return?

yasm32 -f win32 -DPREFIX -o quant-a.obj quant-a.asm

[shin_san]

Hi all, I am a newbee and just need the x264 library to encode some parts of video in an existing vc++ project.

I use msvc 6 + sp6 + nasm + x264-snapshot-20060412-2245 and when I compile, I have 60 syntax errors with \encoder\rdo.c and some other with encoder\macroblock.c ...

May somebody help me?

It s OK, I fixed the problem!!! :)

[bob0r]

would you mind sharing what the problem was?
Information is Power, and Power leads to:

topic- '#x264 - opensource MPEG-4 AVC / H.264 user dicussion - for development see #x264dev - http://videolan.org/x264.html - x264 wins Doom9 codec comparison - will take over the world next'
topic- set by pengvado (Tue 7th Mar 2006 02:38a)

[devaster]

I fixed it : I remove x64 WXP (for today a piece of sh*t ...) iam back on x32 ... but i must reinstall msvs2005 and after this i'll try it ... thanx for reply ...

[shin_san]

Sorry...
I had to replace
if (delta > 32767ll || delta < -32768ll)

by

if (delta > 32767I64 || delta < -32768I64)

in matroska.c

Now it compiles but if I want to #define AVIS_INPUT,
I included <windows.h> and <vfw.h> and liked vfw32.lib, but I have linking problems:

Linking...
x264.obj : error LNK2001: unresolved external symbol _close_file_avis
x264.obj : error LNK2001: unresolved external symbol _read_frame_avis
x264.obj : error LNK2001: unresolved external symbol _get_frame_total_avis
x264.obj : error LNK2001: unresolved external symbol _open_file_avis
bin/x264.exe : fatal error LNK1120: 4 unresolved externals
Error executing link.exe.

x264.exe - 5 error(s), 38 warning(s)

I haven t found any help on the x264-dev posts...

[squid_80]

Those functions are in muxers.c. Did you define #AVIS_INPUT for the whole project or just x264.c?

[shin_san]

only in 264.c ... :confused:

[squid_80]

So define #AVIS_INPUT for muxers.c as well...

[shin_san]

OK, I am a fool...
:stupid:
now it s working :) when I define if in the whole project. Thanks a lot.

[lcx]

In Visual C++ 2005 the following changes in macroblock.h of revision 520 does not compile
static const int x264_pred_i4x4_neighbors[13] =
{
[I_PRED_4x4_HU] = MB_LEFT,
[I_PRED_4x4_H] = MB_LEFT,
[I_PRED_4x4_HD] = MB_LEFT | MB_TOPLEFT | MB_TOP,
[I_PRED_4x4_DDR] = MB_LEFT | MB_TOPLEFT | MB_TOP,
[I_PRED_4x4_VR] = MB_LEFT | MB_TOPLEFT | MB_TOP,
[I_PRED_4x4_V] = MB_TOP,
[I_PRED_4x4_VL] = MB_TOP | MB_TOPRIGHT,
[I_PRED_4x4_DDL] = MB_TOP | MB_TOPRIGHT,
[I_PRED_4x4_DC] = MB_LEFT | MB_TOP,
[I_PRED_4x4_DC_LEFT] = MB_LEFT,
[I_PRED_4x4_DC_TOP] = MB_TOP,
[I_PRED_4x4_DC_128] = 0
};

So I changed it to
static const int x264_pred_i4x4_neighbors[13] =
{
MB_TOP, //I_PRED_4x4_V
MB_LEFT, //I_PRED_4x4_H
MB_LEFT | MB_TOP, //I_PRED_4x4_DC
MB_TOP | MB_TOPRIGHT, //I_PRED_4x4_DDL
MB_LEFT | MB_TOPLEFT | MB_TOP, //I_PRED_4x4_DDR
MB_LEFT | MB_TOPLEFT | MB_TOP, //I_PRED_4x4_VR
MB_LEFT | MB_TOPLEFT | MB_TOP, //I_PRED_4x4_HD
MB_TOP | MB_TOPRIGHT, //I_PRED_4x4_VL
MB_LEFT, //I_PRED_4x4_HU
MB_LEFT, //I_PRED_4x4_DC_LEFT
MB_TOP, //I_PRED_4x4_DC_TOP
0 //I_PRED_4x4_DC_128
};

Is this correct?

[ayanonline]

I have installed gpac-0.4.2-rc2 in my linux fedora core 5 system but when ever I am running MP4Box command it is givving the following error:
MP4Box: error while loading shared libraries: /usr/lib/libgpac.so: cannot restore segment prot after reloc: Permission denied

I have done even chmod 777 libgpac.so and tried to reinstall the total package for several times.

Plzzz suggest what to do.

Thanx in advance.

[bob0r]

In order to compile rev 574 i had to update strip.exe

My old mingw version (mingw that is up to date):
GNU strip 2.15.91 20040904

updated to:

GNU strip 2.16.91 20060119


I got it from someone in #x264, but i believe its in some mingw release candidate.

[hpn]

@Sharktooth, what are your current CFLAGS "custom" options that you build x264 with?
I'm struggling to find some extra stuff to add to the default CFLAGS in the configure (-O4 -ffast-math -fomit-frame-pointer), but seems -O4 implies every possible optimization, so nothing more can be added ( O4 == O3 ? ). Am I wrong?

(except for -march=athlon-xp that seems marginally faster on my CPU despite the asm code in x264, but of course this can't be used for generic builds)

[Sharktooth]

O4 doesnt exist... that means it's the same as O3.
when i have some time i will test:
-floop-optimize2
-funsafe-loop-optimizations
-freorder-blocks-and-partition
-ffloat-store
-funsafe-math-optimizations (edit: useless, already included in -ffast-math)
-fsingle-precision-constant

Pay particular attention to all the FP optimizations. x264 rate control doesnt require ultra precise FP operations, so those opts "should" not screw the results.
Also i do not include those options in my daily builds... they need testing (they may also need GCC 4.1.x, i didnt check if those work on earlier versions).
As for -march i use pentium2 as default

[akupenguin]

Pay particular attention to all the FP optimizations. x264 rate control doesnt require ultra precise FP operations, so those opts "should" not screw the results.
Yes, but by the same token x264 doesn't spend much time doing FP math, so optimizing it doesn't gain much speed. The total amount of time spent in ratecontrol is 0.02% without any FP-specific compile options. So what you really want is options to reduce the size of FP code, possibly at a cost to both precision and speed, because cache effects will make more difference than any direct optimization of FP code.

[Sharktooth]

that's why i want to try -ffloat-store and -fsingle-precision-constant...
those will help optimizing the registers usage (and -freorder-blocks-and-partition will help with paging and cache locality performance).

-ffloat-store
Do not store floating point variables in registers, and inhibit other options that might change whether a floating point value is taken from a register or memory.

This option prevents undesirable excess precision on machines such as the 68000 where the floating registers (of the 68881) keep more precision than a double is supposed to have. Similarly for the x86 architecture. For most programs, the excess precision does only good, but a few programs rely on the precise definition of IEEE floating point. Use -ffloat-store for such programs, after modifying them to store all pertinent intermediate computations into variables.

-fsingle-precision-constant
Treat floating point constant as single precision constant instead of implicitly converting it to double precision constant.
i cant think of anything better to do with CFLAGS. Any ideas are welcome...