[FFmpeg-devel] [PATCH] libavformat/vapoursynth: Update to API version 4, load library at runtime

[Anton Khirnov]

Quoting Stefan Oltmanns via ffmpeg-devel (2024-06-22 03:37:03)
> Hello,
> 
> this is my first patch, I hope I got all the formalities correct.
> 
> The current VapourSynth implementation is rarely used, as it links the
> VapourSynth library at build time, making the resulting build unable to
> run when VapourSynth is not installed. Therefore barely anyone compiles
> with VapourSynth activated.
> 
> I changed it, so that it loads the library at runtime when a VapourSynth
> script should be opened, just like AviSynth does.
> On Windows the DLL from VapourSynth is not installed in the system
> directory, but the location is stored in the Registry. Therefore I added
> some code to read that information from the registry.
> 
> As the V4 API is designed with dynamic loading in mind (only a single
> import), I updated the implementation to V4 (changes are mostly
> superficial, no structural changes). The V4 API is already several years
> old, fully supported since R55 released in 2021.
> 
> I copied the two needed header files directly in a vapoursynth.h,
> removing the need to install VapourSynth on the build machine
> (VapourSynth is also LGPL 2.1 or later, so no license issue). I updated
> the configure so that it checks for the ability to load libraries at
> runtime for VapourSynth, just like AviSynth and activate it if not disabled.
> 
> make fate runs without any issue. I tested VapourSynth input scripts
> with various color formats on different platforms:
> 
> Ubuntu 22.04
> macOS 13 (x86_64)
> macOS 13 (arm64)
> Windows 10 (msys2/gcc)
> 
> It compiles on these platforms without any warning and runs without any
> issues.

Sorry, this is entirely unacceptable.
Especially the part instaling atexit handlers and bundling downstream
headers, but overall we prefer to avoid dlopen.

-- 
Anton Khirnov