views:

534

answers:

2

Hi; I'm trying to build a C++/CLI executable to which I statically link ffmpeg (libavcodec, libavformat, libavutil & swscale). It works fine if I build it normally (without /clr, so no CLR support), it works. However, when I add CLR support, it won't start up with a 0xc000007b. A "Hello World" C++/CLI app runs fine, though.

Supposedly the same thing happens with Boost::Threads, but since ffmpeg is pure C, I doubt it's using Boost.

My config:

  • Visual Studio 2008 Professional SP1
  • Windows XP Pro SP3 (x86)
  • .NET Framework 3.5 SP1

Thanks, Robert

+2  A: 

It might not use boost, but it probably uses threads and thread local storage, which leads to the same problem. CLR is not compatible with __declspec(thread). I believe there is no simple work-around, unless you are willing to modify ffmpeg code (if you are, google those keywords for examples: clr, __declspec(thread) ).

I suggest isolating ffmpeg in a different process and using some means of interprocess communication.

ima
Thanks -- it also seems to work if I link to it dynamically, but a separate process might be still be a better option for preventing memory leaks, etc.
Robert Fraser
+2  A: 

I've seen a similar issue that involved DirectEditServices. The solution ended up being related the Thread Apartment type. In .Net 2.0 and later the default thread apartment type switched from STA to MTA. Some native C++ objects do not support MTA. I had success by spawning a thread and manually setting the apartment type to STA. Keep in mind that any interprocess communications with a native C++ object that does not support STA must occur on the STA thread that instantiates the object.