Just FYI

[Asd-g]

Thanks for this plugin.

I noted Note: This project may not correctly build in MinGW with GCC, I sadly have to recommend MSVC. at the bottom of README.md. You have to use the AviSynth C API instead of AviSynth CPP API in order to use all possible compilers (including MinGW GCC and MSVC). If you want, I can rewrite it in C API (no fork/pull request) so that you can have a C API example.

[LigH-de]

Sure, I don't mind. It is indeed mainly a "proof of concept" project.

I was close to trying it in FreePascal with the Avisynth-C header translation by Myrsloik, but he helped me getting it done this way.

[qyot27]

Just to clarify the issue and expand on what @Asd-g said, since it also popped up a couple times over on Doom9 too:

C++ compilers are not ABI compatible with one another. So you can't mix-and-match MSVC and g++ core and plugins. The core and plugins have to have been built with the same compiler. So if you built the AviSynth+ core with MinGW-w64/GCC (or llvm-mingw/Clang), then plugins built with said MinGW-w64/GCC or llvm-mingw/Clang would work, but MSVC plugins won't. The same incompatibility would [probably] apply for clang-cl vs. mingw64 as well.

[Technically speaking, what I'm describing above is the incompatibility between MSVC's C++ ABI and the Itanium C++ ABI used by basically all of the other major compilers. Clang is a special case; clang-cl mimics MSVC, standard Clang mimics GCC and thereby uses Itanium. This swamp of problems is restricted to Windows, because other OSes all default to either GCC or standard GCC-mode Clang. I've been very tempted to switch Windows ARM64 builds to only support using the Itanium ABI compatible compilers, though, since we're so early that basically no plugin ecosystem for that configuration exists yet; if MSVC provides a full Clang build that can be invoked in standard mode instead of just clang-cl, this could probably be done fairly invisibly to users that have married themselves to MSVC, by way of how CMake gets invoked.]

MSVC and GCC are, however, largely compatible when handling plain C, and whatever differences exist can be papered over with #ifdefs or compiler switches. The C interface for AviSynth was designed and intended to allow users to develop plugins using GCC instead of MSVC (as part of an effort to help facilitate eventual porting of AviSynth to Linux....that only took 17 years or so; the C interface also carved out a niche as the way x264 and FFmpeg interact with AviSynth(+) as a library). So C plugins built with GCC can be loaded by an MSVC-built core - which due to historical inertia, are the standard official builds. Theoretically, it would also allow C plugins built by MSVC to be loaded by a GCC-built core, but that's almost as academic in nature as the way people treat building the core with MinGW-w64 to start with.

This problem with the C++ interface is a reason why one of the stated goals really early on after AviSynth+ was forked was for a future all-new plugin API to be C based, not C++ (it's also the reason why VapourSynth's plugin API has been C from the beginning). It's still fine for the process code itself to be written in C++, but the plugin interface needs to use the C interface for maximum compatibility.

[LigH-de]

I even had the C interface at one point but did not know reasons why it is preferable. This was interesting for sure.