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

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

Am 22.07.24 um 08:57 schrieb Anton Khirnov:
> Quoting Stefan Oltmanns (2024-07-18 14:12:42)
>> Hello Anton,
>>
>> can you eloborate on that? What is unacceptable with my patch that is
>> perfectly fine in the AviSynth input module? It's the very same concept.
>
> It's not perfectly fine in avisynth, I dislike it there as well. There
> are also recent patches that remove the atexit handler.

The atexit will be removed in the next revision of the patch.

>
>> Loading the library at runtime makes it so much more useful, because you
>> can distribute ffmpeg binaries without forcing the user to install
>> VapourSynth (which requires the user to install Python).
>
> Runtime loading hides dependencies from standard tools and makes program
> behaviour harder to analyze. Not to mention you're adding a bunch of
> global state, which is evil.

All global states will be removed in the next revision of the patch.

It's the intention of my patch to reduce ("hide") the VapourSynth
dependency, so unless you want to actually open a VapourSynth script
there is no dependency to it. If you try to open a VapourScript script
without having VapourSynth installed, you'll get an error message.
VapourSynth itself has unclear dependencies, it will load plug-ins on
runtime and as it uses Python you can in fact load other Python
libaries, for example AI stuff like PyTorch for fancy upscaling, that
will then load CUDA/ROCM.

>
>> VapourSynth is not just a library like x264 that you can link in
>> statically if you like, VapourSynth is a frame server (like AviSynth)
>> with it's own dependencies.
>> If you worry about platforms that do not support loading libraries at
>> runtime: VapourSynth is based on plugins that are loaded on runtime, so
>> it won't work on those platforms anyway.
>
> I am worried about special "demuxers" than are not really demuxers and
> don't work like other demuxers, hence massively increasing library
> maintenance load.
>

I somewhat agree here, when I first saw a AviSynth demuxer in the list
of supported formats it looked weird, because it's not a format that you
demux.
But what's the solution? Create a new library like "avframeserver" for 2
(?) different tools? How do they increase the maintinace load? There are
a lot of external libraries that get used by ffmpeg, what's the
difference here? As these formats do not contain any advanced video
codec, but raw video, shouldn't it be rather easy to maintain, because
no weird complications with some decoder?

Best regards
Stefan
_______________________________________________
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".