vapoursynth: Critical: Core plugin autoloading failed. Installation is broken!

[kasper93]

Description / Steps to reproduce the issue

Any script with vspipe --info t.vpy fails. Also mpv fails with Could not find platform dependent libraries <exec_prefix> when trying to use vapoursynth.

Expected behavior

vapoursynth works

Actual behavior

vapoursynth doesn't work

Verification

• [X] I have verified that my MSYS2 is up-to-date before submitting the report (see https://www.msys2.org/docs/updating/)

Windows Version

MINGW64_NT-10.0-22621

MINGW environments affected

• [X] MINGW64
• [X] MINGW32
• [X] UCRT64
• [X] CLANG64
• [X] CLANG32
• [X] CLANGARM64

Are you willing to submit a PR?

No response

[Biswa96]

Would you like to provide the t.vpy file to test with vspipe?

[kasper93]

Any will do, you can copy example from https://www.vapoursynth.com/doc/gettingstarted.html

[Biswa96]

I have added a pull request to fix this issue. The new patch checks if the registry key is present. Would you like to test the packages from GitHub Actions artifacts of that pull request? https://github.com/msys2/MINGW-packages/actions/runs/6702658272

Also, clang32 build has to be disabled due to out-of-memory issue in CI.

[kasper93]

Still doesn't work. You can try with:

mpv --vf=vapoursynth=test.vpy <file>

test.vpy:

from vapoursynth import core

clip = video_in
clip = core.resize.Bicubic(clip, width=1280, height=720)
clip.set_output()

[Biswa96]

It shows a video in my case. I have tried with the sample-3.mkv file from here https://getsamplefiles.com/sample-video-files/mkv (first search result of 'sample mkv file' in duckduckgo).

[Biswa96]

Forgot to mention that, mpv works in ucrt64 without the vapoursynth fix.

[kasper93]

Indeed it works fine when mpv binary is located in /clang64/bin directly. Else it would just fail. Probably vapoursynth cannot find python path or something.

Do you think it is something that could be supported? If not I think the current fix is working as expected with /clang64/bin/mpv.

[Biswa96]

Indeed it works fine when mpv binary is located in /clang64/bin directly. Else it would just fail.

How did you test with mpv outside of msys2 installation?

[kasper93]

How did you test with mpv outside of msys2 installation?

I have my mpv dev build installed to separate prefix meson configure --prefix="$HOME/install", the rest of the build is as normal. My mpv binary lives inside $HOME/install/bin directory and in this case it doesn't work. You probably can just copy mpv.exe binary to local dir and run it for the same effect.

[Biswa96]

Indeed it works fine when mpv binary is located in /clang64/bin directly. Else it would just fail. Probably vapoursynth cannot find python path or something.

Yes, something like that is happening. According to Process Monitor, mpv.exe (or libvapoursynth-script-0.dll) tries to find libvapoursynth.dll in that same directory. Then the same type of errors are cascading to python files.

I think that we should not break the default 'search in same directory' behavior. As mpv is working in $MINGW_PREFIX, changing path may break other things.

[Biswa96]

tl;dr

• vapoursynth: Critical: Core plugin autoloading failed. Installation is broken! - fixed ✔️
• mpv: Could not find platform dependent libraries - only happens if mpv.exe exits outside of $MINGW_PREFIX - not fixed ❌

Here is the full error.

$ ./mpv.exe --vf=vapoursynth=test.vpy sample-3.mkv
 (+) Video --vid=1 (*) (h264 1080x720 25.000fps)
Could not find platform dependent libraries <exec_prefix>
[vapoursynth] Could not initialize VapourSynth scripting.
[user_filter_wrapper] Creating filter 'vapoursynth' failed.
Video: no video
No video or audio streams selected.

Exiting... (Errors when loading file)

[kasper93]

I think that we should not break the default 'search in same directory' behavior. As mpv is working in $MINGW_PREFIX, changing path may break other things.

I don't know how path resolution works in VS. But what I see is that there is portable mode that is disabled by 0002-prevent-portable-python.patch only in vsscript.cpp, but the same logic is applied in vscore.cpp See https://github.com/vapoursynth/vapoursynth/blob/329ca497b17c324eac701aa1b20652e558e5d281/src/core/vscore.cpp#L1817 which is not patched, so this might be a hint why the paths are wrong.

I don't agree it shouldn't be fixed, currently any binary that you build has to reside in $MINGW_PREFIX which is not desirable for any kind of development. VS should base it lookup on own dll or otherwise use system prefix, not try to use portable binary location.

[Biswa96]

In vscore.cpp, portable mode is true only when portable.vs file is present. Otherwise, VS searches in AppData directory. So, it was kept as is.

[Biswa96]

I have reopened the issue if anyone wants to work on that mpv path relocation issue.