Why are frei0r C++ filters DLLs not loading in ffmpeg but C filters do

Question

I am trying to crosscompile ffmpeg with frei0r support for windows 10. On linux (Ubuntu 18.04) all goes flawlessly. On Windows (Mingw-w64 7.3.0 on Ubuntu), build is fine. However, when running on Windows with this command line:

ffmpeg -i http://lb.streaming.sk/fashiontv/stream/playlist.m3u8 -vf frei0r=pixeliz0r -loglevel debug -f mpegts pipe:play | ffplay -loglevel quiet -i pipe:play

I get the right behavior, but with

ffmpeg -i http://lb.streaming.sk/fashiontv/stream/playlist.m3u8 -vf frei0r=vignette -loglevel debug -f mpegts pipe:play | ffplay -loglevel quiet -i pipe:play

I get an error that dll was not found.

[Parsed_frei0r_0 @ 000000000347ef00] Could not find module 'vignette'.
[AVFilterGraph @ 00000000029074c0] Error initializing filter 'frei0r' with args 'vignette'
Error reinitializing filters!
Failed to inject frame into filter network: Invalid argument
Error while processing the decoded data for stream #0:1
[AVIOContext @ 00000000028d8f40] Statistics: 0 seeks, 0 writeouts
[AVIOContext @ 00000000028c5480] Statistics: 133422 bytes read, 0 seeks
[AVIOContext @ 00000000028d1b00] Statistics: 0 bytes read, 0 seeks
[AVIOContext @ 00000000006ccd80] Statistics: 201 bytes read, 0 seeks
[AVIOContext @ 00000000028a8100] Statistics: 137 bytes read, 0 seeks

The same behavior is consistent on Windows, all C plugins work while none of the C++ dll plugins is found. On the linux build they all work without problem.

This is my build config for ffmpeg:

./configure --arch=x86_64 --target-os=mingw32 --cross-prefix=x86_64-w64-mingw32- --disable-doc --enable-nonfree --enable-gpl --enable-version3 --enable-static --disable-shared --enable-frei0r --extra-cflags='-I../frei0r/include -I/usr/local/include -I/usr/share/mingw-w64/include' --extra-ldflags="-static -static-libstdc++ -static-libgcc" --extra-libs='-lstdc++ /usr/local/lib/libdl.dll.a'

I tried to track down the problem and found that for some reason the ffmpeg filter vf_frei0r is not able to open those dlls. More exactly the dlopen returns a null handler after call with dll's path/name. Again, only for C++ ones.

I suspect it might be something related to name mangling in C++, but for what I see frei0r hpp exports all C functions called by dlopen as external.

Any hint, idea on this issue? Thanks.

Answer 1

Answering my own question.

After looking at the generated binaries I found that for some reason, the mingw32-w64 g++ compiler is ignoring the "external C" that is surrounding the frei0r.h include. Because of this the exported symbols have their names mangled as the c++ compiler dictates and are not found when invoked from the C code from ffmpeg.

Update: After more digging I learned that even the C compiler does symbol name decoration, and one way to prevent this is by using .def files (for visual studio) where to define the exported names of your functions.