compiling x264 on windows xp

[ramprasad85]

I downloaded the latest source code of x264 using git.
I opened the x264.sln. using visual studio 2005
when i tried to build, I got a lot of errors.
there were just two problems
1. undefined reference to log2f (analyse.c)
2. variable declarations in the middle of a function. (me.c and slicetype.c)

very easily i could fix these issues and was able to compile. the generated exe is working perfectly.
i noticed that the exe compiled with mingw(from x264.nl) is much faster than the one I compiled. the exe i compiled is using the cpu "feature Slow_mod4_stack" also.

what am i missing? why the code did not compile in visual studio as it is?
:rolleyes:

[Dark Shikari]

We don't support non-C99 compilers anymore, such as MSVC.

Slow-mod4-stack is because MSVC is physically incapable of aligning the stack to 16 bytes, so some assembly functions have to be disabled.

If it's vastly slower (3-7x slower), it could be that you accidentally compiled without assembly code.

If it's only somewhat slower, it could be because x264 has been primarily optimized for GCC, with inline assembly and intrinsics like __attribute__((always_inline)), which may not be enabled (or even exist) for MSVC.

[kemuri-_9]

A. there's a patch from gabriel on the mailing list to support non C-99 compilers (i.e. MSVC), so you can use that here (http://mailman.videolan.org/pipermail/x264-devel/attachments/20090716/7e5153ed/attachment.txt)
B. iirc, the msvc sln is set to "debug" and not "release"
C. iirc, none of the optimizations are actually on for either compilation modes

once you go through the sln settings for "release" and activate the code optimization features, then msvc is pretty close to gcc.

otherwise on default i think it's about 2-3x slower than gcc builds.
don't forget to compile pthreads and link that in as well.

and as Dark_Shikari said, msvc will not be officially supported until it has enough c99 compatibility to compile x264 without errors.
I had tried 2010 beta1 and it still has plenty of c99 incompatibilities so this isn't going to be anytime soon.

[roozhou]

I have been compiling x264 in VS 2005 for a long time. Get the source code from svn.
http://www.sourceforge.net/projects/direct264

Things you should know before compile x264 in VS 2005:
1) You can find compiled pthread.lib and headers in the repository. GPAC sources required by MP4 output modules are also included in the project so you no longer need to compile GPAC.

2) There are no log2f in MSVC's math.h, so you have to add this to osdep.h
#define log2f(x) (logf(x)*1.4426950408889634f)

3) MSVC does not support mixed declaration and statement. If you find any, move all declarations ahead of statements.

4) Though most of x264's time critical functions are coded in .asm files, there are still some functions coded in AT&T-style inline assembly. I have already ported all of them to MASM-style inline assembly. You can find them in osdep.h and util.h.

5) So far I have no idea how to fix the Slow-mod4-stack issue in MSVC. Maybe you can align the stack inside an assembly function but this is not easy work. Anyway these functions have unnoticeable impact on overall encoding speed.

With Profile Guided Optimization my VC 2005 build runs as fast as GCC 4.4.0 build. The performance difference between them are less than 1%.

[Dark Shikari]

4) Though most of x264's time critical functions are coded in .asm files, there are still some functions coded in AT&T-style inline assembly.This is because they're actually inlined. You can't inline NASM assembly.I have already ported all of them to MASM-style inline assembly. You can find them in osdep.h and util.h.Do note that as far as I've been able to tell, it's impossible to get MSVC to use inline assembly well; it will store all the input values to memory, then re-load them back to use them, adding a nasty speed penalty.5) So far I have no idea how to fix the Slow-mod4-stack issue in MSVC. Maybe you can align the stack inside an assembly function but this is not easy work. Anyway these functions have unnoticeable impact on overall encoding speed.No, many of these functions are quite important; it's not just deblocking.With Profile Guided Optimization my VC 2005 build runs as fast as GCC 4.4.0 build. The performance difference between them are less than 1%.How about you compare against ICC?

[roozhou]

This is because they're actually inlined. You can't inline NASM assembly.Do note that as far as I've been able to tell, it's impossible to get MSVC to use inline assembly well; it will store all the input values to memory, then re-load them back to use them, adding a nasty speed penalty.
Agreed. But MSVC does a good job when the input values are directly accessible(not intermediate values).

No, many of these functions are quite important; it's not just deblocking.
AFAIK they are sse2 deblocking functions and sse2/ssse3/sse4.1 hadamard_ac functions. Since x264 will fall back to mmx functinos, it's not as slow as plain c functions.

Why not align the stack inside the assembly functions? You just need an extra registry and two or three more instructions.
e.g.
mov eax, esp
sub esp, xxx
and esp, -16
....
mov esp, eax

How about you compare against ICC?
I compared imk's ICC build with my MSVC build on a Core2, and could hardly find any difference between them. ICC build also suffers from slow-mod4-stack issue:)

[Dark Shikari]

AFAIK they are sse2 deblocking functions and sse2/ssse3/sse4.1 hadamard_ac functions. Since x264 will fall back to mmx functinos, it's not as slow as plain c functions.

Why not align the stack inside the assembly functions? You just need an extra registry and two or three more instructions.
e.g.
mov eax, esp
sub esp, xxx
and esp, -16
....
mov esp, eaxBecause it makes it slower on the compiler that the vast majority of people use ;)

Also, requires an extra register.

[roozhou]

Because it makes it slower on the compiler that the vast majority of people use ;)

Also, requires an extra register.

Does the caller use extra instructions to ensure mod16 stack?

[Dark Shikari]

Does the caller use extra instructions to ensure mod16 stack?No; AFAIK the caller assumes that the stack is mod16 to start with and just adjusts the amount that it subs esp accordingly.

[rallymax]

...2) There are no log2f in MSVC's math.h, so you have to add this to osdep.h
#define log2f(x) (logf(x)*1.4426950408889634f)
...
THANK YOU THANK YOU. You just saved me A LOT of time :thanks::)

[khongminh]

when I compile x264 with VS 2008.
x264-snapshot-20090922-2245
It has errors:

1>libx264 - 0 error(s), 374 warning(s)
Linking...
2>libx264.lib(encoder.obj) : error LNK2019: unresolved external symbol _x264_lookahead_init referenced in function _x264_encoder_open_75
2>libx264.lib(encoder.obj) : error LNK2019: unresolved external symbol _x264_lookahead_is_empty referenced in function _x264_encoder_encode
2>libx264.lib(encoder.obj) : error LNK2019: unresolved external symbol _x264_lookahead_get_frames referenced in function _x264_encoder_encode
2>libx264.lib(encoder.obj) : error LNK2019: unresolved external symbol _x264_lookahead_put_frame referenced in function _x264_encoder_encode
2>libx264.lib(encoder.obj) : error LNK2019: unresolved external symbol _x264_lookahead_delete referenced in function _x264_encoder_close
2>x264 - 6 error(s), 75 warning(s)
========== Rebuild All: 1 succeeded, 1 failed, 0 skipped ==========


How can I fixed that problem?
Thank you so much.

[roozhou]

@khongminh
Do not use snapshots. Checkout direct264 code from https://direct264.svn.sourceforge.net/svnroot/direct264/x264_mbtree

I have done everything for you.

There is an x264_vs2008.sln under build/win32. Open it in VS2008, select Debug and Press F7.
The release build requires compiled ffmpeg libraries, but you can easily remove all lavf staff from the project.

If you are familiar with both Visual Studio and MinGW, it is not very difficult to port x264 to MSVC.
But if you know nothing about the link error you posted, I cannot help.

[khongminh]

Do not use snapshots. Checkout direct264 code from https://direct264.svn.sourceforge.net/svnroot/direct264/x264_mbtree

I have done everything for you.

There is an x264_vs2008.sln under build/win32. Open it in VS2008, select Debug and Press F7.
The release build requires compiled ffmpeg libraries, but you can easily remove all lavf staff from the project.

If you are familiar with both Visual Studio and MinGW, it is not very difficult to port x264 to MSVC.
But if you know nothing about the link error you posted, I cannot help.

Thank you so much.
I downloaded and compiled it. It runs.
But When I run with file foreman.h264 like this:
x264 -o foreman.h264 foreman_qcif_300frms.yuv 176x144
output file is foreman.h264 has problem (it swings or shakes). I run this file by vlc.
I attached this file.
Can you tell me why it happens.