How to build x264 as a dll

[stoneiii]

Hello,
I should change the question into "How to use the libx264-xxx.dll in VC".
I compile the x264 in mingw gcc in Windows to produce a dll for my C++program written in VC.
Now I use function LoadLibrary to run-time load the dll and GetProcessAddress to get the function address I need (for example, x264_defaul_param).
The function address is no empty, but when the program actually calls the function, the system reports a memory error.
Can the dll be called in VC? What shall I do?
Thanks in advance.


/*******************************************************************************************/
I write a screencast program, which involves x264 as video encoder. My program is written in VC. But the x264 source code can only be built in Eclipse(mingw).So I have to build x264 into dll, and use "Load Library" to call the encoder in run-time.

But the problem is I must use the functions in x264.c and x264.c is excluded out of libx264.dll accoding to the default makefile. For example, I re-write the funtions such as "parse", "encode" and add them into x264.c as interface for calling. Since some variables and funtions are defined as static in x264.c, I have to place them in x264.c.
I make the change in the related command:
old way:
#$(SONAME): .depend $(OBJS) $(OBJASM) $(OBJSO)
# $(LD)$@ $(OBJS) $(OBJASM) $(OBJSO) $(SOFLAGS) $(LDFLAGS)

the way I make modification
$(SONAME): .depend $(OBJCLI) $(OBJS) $(OBJASM) $(OBJSO)
$(LD)$@ $(OBJCLI) $(OBJS) $(OBJASM) $(OBJSO) $(SOFLAGS) $(LDFLAGS)

Actually I don't know how to write makefile, so I am not sure whether this change is appropriate.

Now, when I run the program, I can get the runtime address of the functions, but the calling doesn't work right I trace the disassembled codes and then find everytime the program jump to a invalid address.

I have no idea how to handle this problem. So I come to here and ask for help.

[LoRd_MuldeR]

If you use "libx264.dll" (built via GCC/MinGW) from your own application, you should call the "public" API functions of x264 (i.e. those defined in x264.h) only!

And those functions (actually all functions) are exported from the x264 DLL, which means you can call them from your application, for example with LoadLibrary() and GetProcAddress().

The "internal" functions of x264 should never be called from outside. Also I don't think it's a good idea to add your own functions into the x264 DLL. Why you do this?

BTW: I think you don't have to load the x264 DLL via LoadLibrary() at runtime. You can create an import library (.lib) with the "lib.exe" tool of VisualStudio for permanent linkage...

[stoneiii]

If you use "libx264.dll" (built via GCC/MinGW)
The "internal" functions of x264 should never be called from outside. Also I don't think it's a good idea to add your own functions into the x264 DLL. Why you do this?


Because I want to enable my program to receive the input command line as x264.exe does to configure the encoder parameters. This should use some functions x264.c. Furthermore, I want to use x264's functions to write mkv files or flv files. But these functions are also defined as internal use.


BTW: I think you don't have to load the x264 DLL via LoadLibrary() at runtime. You can create an import library (.lib) with the "lib.exe" tool of VisualStudio for permanent linkage...

However, if I want to use static library, I should include some head files. Because of the reasons I mentioned above, I may have to use more functions or structures than x264.h defines, which will involve more header files. But some of them cannot be compile right in VC.
For example, Do I need to call
int x264_threading_init( void )
in my program to initialize multi-threading encoding? If I should, osdep.h cannot be involved in VC because of compiling errors

[kemuri-_9]

Because I want to enable my program to receive the input command line as x264.exe does to configure the encoder parameters. This should use some functions x264.c. Furthermore, I want to use x264's functions to write mkv files or flv files. But these functions are also defined as internal use.

However, if I want to use static library, I should include some head files. Because of the reasons I mentioned above, I may have to use more functions or structures than x264.h defines, which will involve more header files. But some of them cannot be compile right in VC.

if you want to use the x264's codebase directly (without modifications) within MSVC, you'll need Intel's compiler to support x264's C99 usage, which MSVC does not currently and may just never support.

alternately you can try direct264's codebase instead, though unsupported by the primary devs, it's supposed to work with MSVC out of the box.

[LoRd_MuldeR]

Because I want to enable my program to receive the input command line as x264.exe does to configure the encoder parameters. This should use some functions x264.c. Furthermore, I want to use x264's functions to write mkv files or flv files. But these functions are also defined as internal use.

Well, even if you want to re-use some of x264's "internal" code in your own program, but that code doesn't compile with your compiler (i.e. Visual Studio), you basically have 3 different options:
* Port the code to Visual Studio (you can have a look at direct264's codebase, as kemuri-_9 suggested)
* Use Visual Studio with the Intel Compiler, which is supposed to work with x264 code (there is a free trial version of ICL)
* Switch over to MinGW/GCC for your project (or at least for the part that deals with the video encoding)

Still in the third case I'd rather build a "wrapper" library on top of libx264 than squishing you own code into the x264 library.
This way you can later update to newer libx264 easily. If you modify libx264, porting all your changes to a newer version can be pain...

However, if I want to use static library, I should include some head files. Because of the reasons I mentioned above, I may have to use more functions or structures than x264.h defines, which will involve more header files. But some of them cannot be compile right in VC.

You won't be able to link libx264 as a "static" library with Visual Studio - at least not if the static lib was compiled with MinGW/GCC.

As far as I know, Visual Studio doesn't support GCC's library (.a) files. It needs its own (.lib) files.

Nonetheless you can take an existing GCC-compiled x264 DLL and generate an import library for Visual Studio, using the "lib.exe" tool.

This is NOT a "static" library. When you link your app against the import library (.lib file) it will still use the DLL.

But you don't have to load the DLL explicitly at runtime, via LoadLibrary(). Instead the OS' Loader will make sure the DLL is available.

(And of course you'd still use the libx264 API as defined in x264.h)

For example, Do I need to call

int x264_threading_init( void )
in my program to initialize multi-threading encoding? If I should, osdep.h cannot be involved in VC because of compiling errors

No, you don't have to. If x264 was compiled with threads enabled (either PThreads or native Win32 Threads), it takes care of multi-threading (including all required initialization) internally. You don't have to call any of x264's internal functions. Just use the plublic API, as intended...

[TheRyuu]

You won't be able to link libx264 as a "static" library with Visual Studio - at least not if the static lib was compiled with MinGW/GCC.

As far as I know, Visual Studio doesn't support GCC's library (.a) files. It needs its own (.lib) files.

You can generally link static libs when targetting x86 without issue (ffms2 does it with libav), however x64 takes a bit more effort and probably won't work unless using very specific version of certain build tools (i.e. don't do it).

[stoneiii]

Thanks to you guys.
But I find a new problem with my program that when I use original makefile to make a dll, and use LoadLibrary to call a function declared in x264.h(x264_param_default), the program still goes to a memory access conflict.
I do not make any modification. What this error results from? Shall I made some changes in makefile or in source code to enable the C dll to be called in C++ program?

[LoRd_MuldeR]

I do not make any modification. What this error results from? Shall I made some changes in makefile or in source code to enable the C dll to be called in C++ program?

Should be perfectly possible to call C functions from a C++ code. The other way around would be the "problematic" one.

I think you should make a debug build and backtrace the error, so you can find out where exactly it crashes...

(In the past there were some problems when the calling application left the stack unaligned, but x264 assumed the stack to be aligned and thus could crash. But I think it is fixed long ago)