What are the technical differences between a plugin and script?

[ghost]

I see plugin and script more or less used interchangeably. Sometimes when a C++ plugin is used (Though I can also use C if I desired to?), it is distributed as a dll. Does that mean that it only intends to read windows shared libraries (.dll files) when doing more advanced things? And what scenarios would I or rather should I make a compiled plugin instead of just a script? This program got my attention because I was looking for a flexible scripted way to do any video editing and this seems to fit the bill.

[qyot27]

User-defined functions are internal to the AviSynth scripting language, and it's a user decision whether to encapsulate it in its own script file and use the Import() function or the core's autoloading ability to load it into a more typical script that loads a piece of media and manipulates it.

Plugins have more flexibility because they're written in a more normal programming language and can do the sorts of things those can do: SIMD optimizations, wrapping external libraries like FFmpeg or fftw3, any difference in how performance can just differ between a scripting language and a bytecode compiled version of the algorithm/task with the kinds of optimizations the compiler can provide, etc.

Whether to use the C++ or C plugin interface API is a choice of personal comfort as well as portability. If it needs to be portable among compilers and operating systems, use the C interface. The C++ interface has more historical inertia, but because it wasn't implemented in a more portable way, it requires the core and plugin to have been built with the same compiler, and we can't change that without breaking compatibility. Not a problem on other OSes, but on Windows it matters; x86(-64) releases are built with MSVC for compatibility reasons, but ARM and any other architecture going forward use llvm-mingw (or potentially GCC, whenever a fully usable aarch64-w64-mingw32 GCC environment can be built).

[ghost]

One thing that's giving me a headache is the build order for debian. I can build avisynth without issue, I figured out how to link ffmpeg with my local avisynth build, but is building ffms2 truly necessary for usage of avisynth? And it appears that the only video player that works with avisynth on GNU/Linux is either mplayer based (Such as mvp) or vlc. I presume I would have to rebuild mpv/vlc against my patched build of ffmpeg?

[qyot27]

Generally, AviSynth filters are divided into two broad categories: source filters, and processing filters (and processing filters can be subdivided even further based on what they actually do). Source filters are responsible for importing the actual media, while processing filters are the ones doing most of any possible manipulation to that media that you want to do.

Some source filters do exist in the core, but either for simple info (Version()), test patterns (ColorBars()) or as a base to construct things on top of (BlankClip()). On Windows, the AVISource() filter uses the Video for Windows multimedia framework to import files (per the name, mostly AVI files, given what VfW is; but WavSource() is under the same umbrella, using the ACM).

There are several plugins distributed with the core, two of them are source filters. DirectShowSource (Windows only) uses DirectShow as its decoder mechanism, much the same way AVISource uses Video for Windows. The other, ImageSource, can import stills or image sequences in .png, .jpg, .bmp, and other formats. Unlike DirectShowSource, ImageSource is cross-platform. So technically, you could get by with just ImageSource by deconstructing a video down to a folder full of individual frames and load it into AviSynth+ as an image sequence. It's just that that is pretty cumbersome.

FFMS2 uses FFmpeg as its decoder/import mechanism, and thus is completely untethered from any OS-specific media framework. The same is true of LSMASHSource, which also uses FFmpeg. There are also other plugins like D2VSource or RAWSource that specialize in one/few formats. But because FFMS2 or LSMASHSource are the most general-purpose and platform independent, those are typically going to be the ones to use on *nix unless there's a specific need to use something else. Eventually, I would like to have a set of source filters in the core for at least GStreamer, AVFoundation, and MediaKit, so that all the main OSes we support have a framework-based source filter included by default.

It may seem a bit ugly, but one of the cleanest ways to get FFMS2 or LSMASHSource working is to build a stripped-down (basically just decoders and demuxers), static version of FFmpeg that gets installed in a local prefix, and then link FFMS2/LSMASHSource against [i]that[/i] FFmpeg by redirecting PKG_CONFIG_PATH and setting LDFLAGS=-Wl,-Bsymbolic, rather than the one on the system (or in ~/.local/bin).

Yes, mpv or VLC need to be rebuilt against the AviSynth-aware build of FFmpeg, especially if you want to having playback seeking work. A more roundabout way would be to pipe the output from either avs2yuv (avs2yuv test.avs -o - | mpv -) or FFmpeg to mpv or VLC (ffmpeg -i test.avs -vcodec copy -acodec copy -f nut - | mpv -), but you can't seek (and avs2yuv only pipes video). avs2yuv also provides some nice processing/benchmarking stats, but it also doesn't handle audio.