search

lordmulder / Simple-x264-Launcher

Simple x264/x265 Launcher
http://muldersoft.com/
GNU General Public License v2.0
151 stars 19 forks source link

Vapoursynth plugin and script folders need update #16

Closed gundamftw closed 5 years ago

gundamftw commented 5 years ago

New version of Vapoursynth now can get their plugin from the VS repository through Python, which default storing path for Windows is

Binaries: C:\Users\myname\AppData\Roaming\VapourSynth\plugins64 Scripts: C:\Users\myname\AppData\Roaming\Python\Python37\site-packages

lordmulder commented 5 years ago

Okay, but what does it mean for Simple x264 Launcher ❓

I just tried with latest Python 3.7.3 and latest VapourSynth R45. And everything seems to work as expected, even though I don't how to install "plugin from the VS repository through Python". I just install plugins by placing them in the "plugins32" or "plugins64" directory, respectively. This seems to work as always. But, anyways, I think it is VapourSynth's job to pick up the plug-ins from the correct directory, right?

Can you please elaborate what exactly you think should be changed on the Simple x264 Launcher side?

Regards.

gundamftw commented 5 years ago

There's the VSRepo plugin manager now that we can get plugins from without looking for them elsewhere. And it installed them on the paths I listed above. Vapoursynth will look for plugins from those location as well as the native plugin32/plugin64 folders.

I have most of the plugins in my vsrepo plugins path but not in the native plugin64 folder and Simple x264 Launcher gives me errors about missing plugins when I loaded in the script.

lordmulder commented 5 years ago

Well, still my question: What exactly needs to be changed on the Simple x264 Launcher side? 😨

Simple x264 Launcher is just a GUI front-end that launches VSPipe.exe and passes your .vpy script as an argument to VSPipe. That's it! It is up to VapourSynth to load the plug-ins from the respective directories. I am not aware of a way how Simple x264 Launcher could force VapourSynth (VSPipe) to load additional plug-ins or to scan additional plug-in directories. And I also don't think this should be necessary.

I think you should try to load your script with VSPipe.exe directly, from the terminal.

For example:

C:\Program Files (x86)\VapourSynth\core64>vspipe.exe --info c:\foo\bar.vpy -
Width: 720
Height: 1280
Frames: 4265
FPS: 25/1 (25.000 fps)

Can you get that to work with the "problematic" script ???

BTW: You are using 32-Bit or 64-Bit VapourSynth? Keep in mind that Simple x264 Launcher defaults to the 32-Bit version, but the 64-Bit version can be activated (if available) via the "Preferences". Whatever VapourSynth version (32-Bit or 64-Bit) you are using, the plug-ins need to have the matching "bitness"!

gundamftw commented 5 years ago

I"m using 64 bit Vapoursynth and Simple x264 Launcher was set to use 64 bit. I ran the that vspipe command on my script in the terminal and it worked. I loaded the script in vs editor and it worked too. But Simple x264 Launcher complains about missing plugin when trying to encode

[2019-05-05][14:35:17] --- GET SOURCE INFO --- [2019-05-05][14:35:17] [2019-05-05][14:35:17] Creating process: [2019-05-05][14:35:17] "C:\Program Files (x86)\VapourSynth\core64\vspipe.exe" --info F:\test.vpy - [2019-05-05][14:35:17] [2019-05-05][14:35:17] Script evaluation failed: [2019-05-05][14:35:17] Python exception: No attribute with the name knlm exists. Did you mistype a plugin namespace? [2019-05-05][14:35:17] Traceback (most recent call last): [2019-05-05][14:35:17] File "src\cython\vapoursynth.pyx", line 1927, in vapoursynth.vpy_evaluateScript [2019-05-05][14:35:17] File "src\cython\vapoursynth.pyx", line 1928, in vapoursynth.vpy_evaluateScript [2019-05-05][14:35:17] File "F:\test.vpy", line 8, in [2019-05-05][14:35:17] clip = core.knlm.KNLMeansCL(clip) [2019-05-05][14:35:17] File "src\cython\vapoursynth.pyx", line 1522, in vapoursynth.Core.getattr [2019-05-05][14:35:17] AttributeError: No attribute with the name knlm exists. Did you mistype a plugin namespace? [2019-05-05][14:35:17] [2019-05-05][14:35:17] PROCESS EXITED WITH ERROR CODE: 1

lordmulder commented 5 years ago

I"m using 64 bit Vapoursynth and Simple x264 Launcher was set to use 64 bit. I ran the that vspipe command on my script in the terminal and it worked. I loaded the script in vs editor and it worked too. But Simple x264 Launcher complains about missing plugin when trying to encode

If the invocation vspipe.exe --info F:\test.vpy - works flawlessly when you run it directly from the terminal, then I have absolutely no idea why this exactly same invocation should fail in Simple x264 Launcher – provided that we are certain that the exactly same vspipe.exe file is used in both cases.

After all, Simple x264 Launcher does nothing but just launching vspipe.exe in the described way 😐

BTW: If you run vspipe.exe --help in the terminal, you will see that there are no options available that concern the loading of plug-ins. So, I really don't know what Simple x264 Launcher could do differently from what we are doing now in order to fix your "problem". If you have an idea, please give me some hint...

gundamftw commented 5 years ago

It only works when I only use filters from the vs plugin64 folder in my script.

In my test script here, I have KNLMeansCL.dll in the vsrepo plugin folder and plugin64 folder don't, and then the program complains about it. If I removed the knlmeanscl call in the script, it worked.

lordmulder commented 5 years ago

It only works when I only use filters from the vs plugin64 folder in my script.

In my test script here, I have KNLMeansCL.dll in the vsrepo plugin folder and plugin64 folder don't, and then the program complains about it. If I removed the knlmeanscl call in the script, it worked.

But why should VapourSynth behave differently and load plug-ins from some additional directory only when you run vspipe.exe manually from the terminal, but not when it gets invoked by Simple x264 Launcher?

Only possible explanations I can think of:

Unless you can figure out what exactly makes the difference, I can't help. I can only speculate 😟

gundamftw commented 5 years ago

Can you reproduce the issue with the vsrepo plugin folder on your machine? If it doesn't work either then I'll report the issue to the vapoursynth thread.

lordmulder commented 5 years ago

Can you reproduce the issue with the vsrepo plugin folder on your machine? If it doesn't work either then I'll report the issue to the vapoursynth thread.

I usually just put plug-ins into the plugins32 or plugins64 folder and that's it. I have no experience with "VSRepo". If you can give me specific instructions, I may be able to give it a try...

gundamftw commented 5 years ago

VSRepo came with the latest Vapoursynth installer, recently there's a VSRepoGUI that make it a lot easier to use, just download this GUI and run it and plugins can be installed in one click: https://forum.doom9.org/showthread.php?t=176313

For the test, just install any plugin in VSRepoGUI that is not on your native plugin64 folder, and then call that plugin in the script and see if Simple x264 Launcher can encode that.

lordmulder commented 5 years ago

Never mind, I got it to work.

After some testing it seems to me that VapourSynth (vspipe.exe) requires the environment variable %USERPROFILE% to be set to the user's profile directory. Otherwise it won't auto-load plug-in DLLs from <AppData>\VapourSynth\plugins{32|64} directory. This is kind of weird, because the proper way to figure out that directory would be the %APPDATA% environment variable – or even better the SHGetKnownFolderPath() system function, because environment variable tend to be unreliable :anguished:

Anyway, I added a workaround to set up %USERPROFILE% for the vspipe.exe process:

image

Regards, MuldeR

lordmulder commented 5 years ago

Please give it a try with the latest TEST version: ~x264_launcher-TEST.2019-05-06.exe~

gundamftw commented 5 years ago

It works, no more error

lordmulder commented 5 years ago

~x264_launcher-TEST.2019-05-07.exe~

lordmulder commented 5 years ago

~x264_launcher-TEST.2019-05-09.exe~

lordmulder commented 5 years ago

Thanks for confirming! Here is another small update: x264_launcher-TEST.2019-05-11.exe

So I hope we can finally close this issue now 😌