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

Stephen Hutchinson qyot27 at gmail.com
Sat Jun 22 09:27:01 EEST 2024


On 6/21/24 9:37 PM, Stefan Oltmanns via ffmpeg-devel wrote:
> 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.
> 

How many distros package VapourSynth yet don't enable it in FFmpeg vs.
both not packaging it and not enabling it?  VapourSynth not being
available as a package in the distro's repository is a far more likely
reason than linking is.

Switching to dynamic loading would absolutely make the experience on or
building for Windows smoother, and would remove the need to rebuild
FFmpeg when VapourSynth updates, outside of future API changes the
demuxer would need to actively account for.

> 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.
> 

That function is in the wrong place.

> 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.
> 

Including local copies of the headers in compat/ wasn't acceptable for
AviSynth (and were removed as soon as it was no longer necessary for 
there to be an OS distinction between what headers were being used),
it's not going to be acceptable for this either.

And setting it up as autodetect seems like overreach.  I don't know if
there's any actual written rule about which libraries to autodetect and
which ones require explicit enabling, but most of the autodetected ones
thus far appear to be OS-level or otherwise foundational libraries, not
libraries for a singular media format.


More information about the ffmpeg-devel mailing list