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

Reply via email to