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.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
