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

[Paul B Mahol <onemda@gmail.com>]

On Tue, Jun 25, 2024 at 11:10 AM Anton Khirnov <anton@khirnov.net> wrote:

> Quoting Stefan Oltmanns via ffmpeg-devel (2024-06-22 03:37:03)
> > Hello,
> >
> > this is my first patch, I hope I got all the formalities correct.
> >
> > 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.
> >
> > 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.
> >
> > As the V4 API is designed with dynamic loading in mind (only a single
> > import), I updated the implementation to V4 (changes are mostly
> > superficial, no structural changes). The V4 API is already several years
> > old, fully supported since R55 released in 2021.
> >
> > 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.
> >
> > make fate runs without any issue. I tested VapourSynth input scripts
> > with various color formats on different platforms:
> >
> > Ubuntu 22.04
> > macOS 13 (x86_64)
> > macOS 13 (arm64)
> > Windows 10 (msys2/gcc)
> >
> > It compiles on these platforms without any warning and runs without any
> > issues.
>
> Sorry, this is entirely unacceptable.
> Especially the part instaling atexit handlers and bundling downstream
> headers, but overall we prefer to avoid dlopen.
>

Dunno what 'we' means here.

$ grep dlopen */*.c
libavcodec/amfenc.c:    ctx->library = dlopen(AMF_DLL_NAMEA, RTLD_NOW |
RTLD_LOCAL);
libavcodec/mediacodec_wrapper.c:    format->libmedia =
dlopen("libmediandk.so", RTLD_NOW);
libavcodec/mediacodec_wrapper.c:    codec->libmedia = dlopen(lib_name,
RTLD_NOW);
libavcodec/mfenc.c:    c->library = dlopen("mfplat.dll", 0);
libavcodec/omx.c:        s->lib2 = dlopen(libname2, RTLD_NOW | RTLD_GLOBAL);
libavcodec/omx.c:    s->lib = dlopen(libname, RTLD_NOW | RTLD_GLOBAL);
libavfilter/af_ladspa.c:        ret = dlopen(path, RTLD_LOCAL|RTLD_NOW);
libavfilter/af_ladspa.c:        s->dl_handle = dlopen(s->dl_name,
RTLD_LOCAL|RTLD_NOW);
libavfilter/vf_frei0r.c:    *handle_ptr = dlopen(path, RTLD_NOW|RTLD_LOCAL);
libavfilter/vf_telecine.c: * @file telecine filter, heavily based from
mpv-player:TOOLS/vf_dlopen/telecine.c by
libavfilter/vsrc_ddagrab.c:    user32_module = dlopen("user32.dll", 0);
libavformat/avisynth.c:    avs_library.library = dlopen(AVISYNTH_LIB,
RTLD_NOW | RTLD_LOCAL);
libavutil/hwcontext_d3d11va.c:    d3dlib  = dlopen("d3d11.dll", 0);
libavutil/hwcontext_d3d11va.c:    dxgilib = dlopen("dxgi.dll", 0);
libavutil/hwcontext_d3d12va.c:    priv->d3d12lib = dlopen("d3d12.dll", 0);
libavutil/hwcontext_d3d12va.c:    priv->dxgilib  = dlopen("dxgi.dll", 0);
libavutil/hwcontext_dxva2.c:    priv->d3dlib = dlopen("d3d9.dll", 0);
libavutil/hwcontext_dxva2.c:    priv->dxva2lib = dlopen("dxva2.dll", 0);
libavutil/hwcontext_mediacodec.c:    s->libmedia = dlopen("libmediandk.so",
RTLD_NOW);
libavutil/hwcontext_vaapi.c:            HANDLE dxgi = dlopen("dxgi.dll", 0);
libavutil/hwcontext_vulkan.c:        p->libvulkan = dlopen(lib_names[i],
RTLD_NOW | RTLD_LOCAL);
libavutil/macos_kperf.c:    av_assert0(kperf =
dlopen("/System/Library/PrivateFrameworks/kperf.framework/Versions/A/kperf",
RTLD_LAZY));




>
> --
> Anton Khirnov
> _______________________________________________
> 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".
>
_______________________________________________
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".