☰

Warum werden frei0r C++ Filter-DLLs in ffmpeg nicht geladen, C-Filter jedoch schon?

tag-icon • tag-icon windows ffmpeg c++
Warum werden frei0r C++ Filter-DLLs in ffmpeg nicht geladen, C-Filter jedoch schon?

Ich versuche, ffmpeg mit Frei0r-Unterstützung für Windows 10 zu plattformübergreifend zu kompilieren. Unter Linux (Ubuntu 18.04) läuft alles reibungslos. Unter Windows (Mingw-w64 7.3.0 unter Ubuntu) läuft der Build einwandfrei. Unter Windows mit dieser Befehlszeile läuft es jedoch:

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

Ich bekomme das richtige Verhalten, aber mit

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

Ich erhalte die Fehlermeldung, dass die DLL nicht gefunden wurde.

[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

Dasselbe Verhalten tritt unter Windows auf, alle C-Plugins funktionieren, während keines der C++-DLL-Plugins gefunden wird. Unter Linux funktionieren sie alle ohne Probleme.

Dies ist meine Build-Konfiguration für 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'

Ich habe versucht, das Problem aufzuspüren und habe festgestellt, dass der FFMPEG-Filter vf_frei0r diese DLLs aus irgendeinem Grund nicht öffnen kann. Genauer gesagt gibt dlopen nach dem Aufruf mit dem Pfad/Namen der DLL einen Null-Handler zurück. Auch hier gilt dies nur für C++-DLLs.

Ich vermute, dass es etwas mit der Namensverstümmelung in C++ zu tun haben könnte, aber soweit ich sehe, exportiert frei0r hpp alle von dlopen aufgerufenen C-Funktionen als extern.

Irgendein Hinweis, eine Idee zu diesem Problem? Danke.

Antwort1

Ich beantworte meine eigene Frage.

Nachdem ich mir die generierten Binärdateien angesehen hatte, stellte ich fest, dass der Mingw32-W64-G++-Compiler aus irgendeinem Grund das „externe C“ ignoriert, das das Include frei0r.h umgibt. Aus diesem Grund werden die Namen der exportierten Symbole so verstümmelt, wie es der C++-Compiler vorgibt, und sie werden nicht gefunden, wenn sie aus dem C-Code von ffmpeg aufgerufen werden .

Aktualisieren: Nach weiteren Recherchen habe ich erfahren, dass sogar der C-Compiler Symbolnamendekorationen vornimmt. Eine Möglichkeit, dies zu verhindern, besteht in der Verwendung von DEF-Dateien (für Visual Studio), in denen die exportierten Namen Ihrer Funktionen definiert werden.

verwandte Informationen