The VideoLAN Forums

Dear all

I would like to develop an application on top of libvlc. The development platform (dictated by other needs) is MS Windows XP , Visual Studio 8, using the intel c compiler 10.0 (supposed to be compatible with GCC 3.2), MultiThreaded (MT) run time library. After some searching, I located and installed libvlc.dll.a to link with. My (for the moment embryonical) application compiles and links nicely, but crashes with a access violation during its first (and for the moment only) call to a libvlc function. Details below. I don't think the program code is the problem. It must be some compiler setting, or the compiler is unsuited, or am I linking against the wrong library? (I didn't consider the .net wrappers, as I'm trying to stay away as must as possible from MS windows specific libraries in my code - the same code should compile and run on mac and linux as well).

Any clue would be highly welcome.

Best and thanks a lot in advance,

Philippe.

main.cpp

extern "C" {
#include "vlc/vlc.h"
}

int main(int argc, char **argv)
{

libvlc_exception_t ex;
fprintf(stderr, "main.cpp:%d\n", __LINE__); // we get here (line 129)
libvlc_exception_init(&ex);
fprintf(stderr, "main.cpp:%d\n", __LINE__); // but not here.


}

Program output:

...
main.cpp:129
main: Caught unhandled exception:
Fri Jul 24 18:18:40 2009
ACCESS VIOLATION: The thread tried to read from or write to a virtual address for which it does not have the appropri
access.
WHILE writing ADDRESS 0x00432E7F
EXECUTING AT ve_setup_XX_uncoupled() [0x009097E3]

Have you tried GCC?

ICC works pretty much out-of-the-box against LibVLC on Linux, but I don't know the settings on Windows. Try to check the calling conventions.

Problem solved: I was using the wrong library.

There are essentially two ways of linking applications with libvlc.dll under windows.
The first is to use explicit linking: LoadLibrary, GetProcAddress, ... (same strategy used to program with OpenGL extensions e.g.) - works, but cumbersome.
The second is to use implicit linking, in human speech: link your application with a .lib file that describes what the .dll offers - easiest, preferred.
But there is no .lib file with the videolan distribution on windows.
The solution is to create one from libvlc.dll.
It takes some searching to find out how to do that. here's the result:

"c:\Program Files\Microsoft Visual Studio 8\vc\bin\dumpbin.exe" /exports /out:libvlc.def libvlc.dll

Edit libvlc.def. Add a line on top, saying "EXPORTS" .
Retain the names of the symbols in the dll on subsequent lines (one symbol name per line)

"c:\Program Files\Microsoft Visual Studio 8\vc\bin\lib.exe" /def:libvlc.def /out:libvlc.lib

The details:

viewtopic.php?f=32&t=53107
http://support.microsoft.com/kb/131313
http://msdn.microsoft.com/en-us/library ... S.80).aspx
http://social.msdn.microsoft.com/Forums ... 043f732d68

Best regards and thanks for your replies,

Philippe.

Hi Philippe,
Thanks for your post. I think we still require the other dll files in the plugins folder at libvlc runtime. Am I right?
FYI, I've been using your first described method in my libvlc app.

Hi Charlest,

Sure, you do require the plugin dlls, but there is no need to convert them to lib files.
Use the --plugin-path command line argument to tell libvlc where to find these dlls, when creating a libvlc instance with libvlc_new(). This is shown in the libvlc programming examples on the videolan web site.

Best regards,

Philippe.

Oh. You can use the same trick as explained above to create a libvlccore.lib file for programming with internal vlc functions in libvlccore.dll .
Best,

Philippe.

What about all the plugins dlls, could I convert all of them into libs?

You shoudn't use the plugins dll, but just libvlccore or libvlc

Is there a noticeable performance gain from using ICC to compile VLC for use on recent Intel architecture (ie. Core2 or i7)?

Noone tried

Ok, I'm curious now. I'll get my hands on what I need for these tests. Any ideas on which encoder could potentially gain the most from ICC: MPEG-2, AVC (H264), Dirac, A52, MP3, Ogg, AAC?

You'd need to rebuild the codec library with ICC...