Am 22.06.24 um 08:27 schrieb Stephen Hutchinson:
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.
I don't know the extact reason, but VapourSynth is not just a library
like avisynth, but an application that uses Python, meaning a lot of
dependencies.
Additionally VapourSynth can nowadays be installed using pip, so no
reason to package it for distros anymore.
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.
Exactly
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 thought that to, should it be in /compat as w32registry.h or something
like that?
But what exactly should it contain?
I could make a function that would be used like
get_w32_regsitry_str(HKEY_CURRENT_USER, L"SOFTWARE\\VapourSynth",
L"VSScriptDLL");
That would return a utf8 string on success and NULL on failure
But that would still contain 3 Windows-specific constants in the
function call. Also is it useful to write the literals as utf-8 just for
them to be converted to wchar again or should it just take WCHAR and
return utf8?
Or shoulds the entire function be located in
/compat/vapoursynth/w32_vsscript_dll.h as "get_w32_vsscript_dll" or
something similar?
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.
As distros probably won't package VapourSynth as it can be installed
using pip, they probably won't build ffmpeg with VapourSynth support,
because they don't have the headers on the build system.
Even when someone decides to build ffmpeg for themself with VapourSynth
support, it will fail unless they have manually build VapourSynth,
because pip won't install any header.
That was my motivation to include those headers. Is there a specific
rule when it is allowed to include headers for external libaries?
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.
I did not find any rule on that. I made it autodetect, because I saw no
negative impact (same license and no dependency at runtime).
_______________________________________________
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".
