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

[Stefan Oltmanns via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>]

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-request@ffmpeg.org with subject "unsubscribe".