Vapoursynth

[feisty2]

I tried to move the vsapi global variable out of the Create function by using getVapourSynthAPI(), I got an undefined symbol error (undefined reference to getVapourSynthAPI)

[Myrsloik]

Is BestAudioSource.dll working with portable setup? For latest downloads it gives me error that it is older API 3.6 and BestAudioSource needs 3.7.
from vapoursynth import core
print(vs)
print(core.version())
core.std.LoadPlugin(r'F:\portable_vs\vapoursynth64\plugins\BestAudioSource.dll')
#
audio = vs.core.bas.Source('video.mp4', track=-1)
audio.set_output(1)

F:\portable_vs>python --version
Python 3.8.2

F:\portable_vs>python audio.py
<module 'vapoursynth' from 'F:\\portable_vs\\vapoursynth.cp38-win_amd64.pyd'>
VapourSynth Video Processing Library
Copyright (c) 2012-2020 Fredrik Mellbin
Core R49
API R3.6
Options: -

Traceback (most recent call last):
File "audio.py", line 6, in <module>
core.std.LoadPlugin(r'F:\portable_vs\vapoursynth64\plugins\BestAudioSource.dll')
File "src\cython\vapoursynth.pyx", line 1852, in vapoursynth.Function.__call__
vapoursynth.Error: Core only supports API R3.6 but the loaded plugin requires API R3.7; Filename: F:\portable_vs\vapoursynth64\plugins\BestAudioSource
.dll; Name: Best Audio Source

Obviously audio things only work in the experimental audio builds

[feisty2]

ahh... it seems I have to link vaporsynth.lib for this function

[_Al_]

Obviously audio things only work in the experimental audio builds
Ok, thank you.

[LoRd_MuldeR]

I noticed the following problem after updating to VapourSynth r49:
[Check for VapourSynth support]
VapourSynth thread has been created, please wait...
VapourSynth 64-Bit support is being tested.
VapourSynth EXE: C:/Program Files/VapourSynth/core/vspipe.exe
VapourSynth DLL: C:/Program Files/VapourSynth/core/vapoursynth.dll
VSPIPE.EXE failed with code 0xC0000135 -> discarding all output!

When I try to run vspipe.exe manually, from the VapourSynth directory, then I get this:

https://i.imgur.com/csSJdII.png

Note that Python v3.8 is installed on my system, and it also was recognized properly by the VapourSynth r49 installer. Tried to re-install, but didn't change anything.

Anyway, went back to r48 and everything works fine:

[Check for VapourSynth support]
VapourSynth 64-Bit support is being tested.
VapourSynth EXE: C:/Program Files/VapourSynth/core/vspipe.exe
VapourSynth DLL: C:/Program Files/VapourSynth/core/vapoursynth.dll
VapourSynth version was detected successfully.
VapourSynth 64-Bit edition found!
VapourSynth thread finished.
VapourSynth support is officially enabled now! [x86=0, x64=1]

https://i.imgur.com/g5KcS7V.png

Any idea what is going on with VapourSynth r49? Apparently vspipe.exe (or more specifically vsscript.dll) fails to locate/load the Python DLL.

[stax76]

Are both python and vapoursynth in path? I had a minor hiccup updating to python 3.8 and vs r49 but could solve it after 2 minutes.

[LoRd_MuldeR]

Are both python and vapoursynth in path?

Nope, they are not. But that's the same for Python 3.8 and Python 3.7! Still, the 'vspipe.exe' from VapurSynth r48 obviously was able to find and load the Python DLL.

IMO, applications should not rely on PATH for DLL loading anyway, as it is highly unreliable. And it also opens the attack vector of picking up "malicious" DLLs from any of the directories that happen to be on PATH.

[stax76]

Made a test and removed vs from path, staxrip and mpc-be still work but mpv(.net) now cannot open vpy, I think mpv uses lavf to open vpy and the authors of that code are mpv authors.

Removed python from path, both mpc-be and staxrip stopped working... not even vfw based VirtualDub2 can open vpy now.

python and vs are per user installed.


edit:

Maybe part of the problem is that there are different python versions and distributions and setup options, and they use all different reg keys, staxrip finds it with multiple strategies:

https://github.com/staxrip/staxrip/blob/master/General/Package.vb#L2118

https://github.com/staxrip/staxrip/blob/master/General/Package.vb#L2226

But it doesn't even need python, it only verifies it because if staxrip cannot find it then vs will probably also not find it and not work.

[Patman]

Any idea what is going on with VapourSynth r49? Apparently vspipe.exe (or more specifically vsscript.dll) fails to locate/load the Python DLL.

I also had problems updating to Vapoursynth R49. The following helped me: Vapoursynth R48 / R49 and Python 3.7.x / 3.8.x completely uninstalled (including registration files), install Python 3.8.2 globally for all users (customized installation) and then install Vapoursynth R49 as admin. That should actually work. An update from Python 3.7.x to 3.8.x does not work properly ...

[LoRd_MuldeR]

I also had problems updating to Vapoursynth R49. The following helped me: Vapoursynth R48 / R49 and Python 3.7.x / 3.8.x completely uninstalled (including registration files), install Python 3.8.2 globally for all users (customized installation) and then install Vapoursynth R49 as admin. That should actually work. An update from Python 3.7.x to 3.8.x does not work properly ...

I have Python 3.8 installed globally, for all users (customized installation).

The problem is that 'vspipe.exe' depends 'vsscript.dll', which in turn depends on 'python38.dll'. The dependency of 'vspipe.exe' to 'vsscript.dll' is no problem at all, as they both reside in the same directory (VapurSynth install directory). However, the 'python38.dll' resides in the separate Python 3.8 install directory, which can not be assumed to be on PATH, or any other directory that Windows searches for DLLs by default.

Now, there actually is code in the vsscript_init() function in 'vsscript.dll' that will determine the path of Python from the registry and explicitly load 'python38.dll' via LoadLibraryEx() function. Unfortunately, starting with VapourSynth r49, we don't even get to that point! There now seems to be a "static" dependency of 'vsscript.dll' to 'python38.dll', so that the Windows loader fails to load/run the 'vspipe.exe' at all...

VapourSynth r48:
https://i.imgur.com/hFncIQa.png

VapourSynth r49:
https://i.imgur.com/bawwzCx.png

[Myrsloik]

I have Python 3.8 installed globally, for all users (customized installation).

The problem is that 'vspipe.exe' depends 'vsscript.dll', which in turn depends on 'python38.dll'. The dependency of 'vspipe.exe' to 'vsscript.dll' is no problem at all, as they both reside in the same directory (VapurSynth install directory). However, the 'python38.dll' resides in the separate Python 3.8 install directory, which can not be assumed to be on PATH, or any other directory that Windows searches for DLLs by default.

Now, there actually is code in the vsscript_init() function in 'vsscript.dll' that will determine the path of Python from the registry and explicitly load 'python38.dll' via LoadLibraryEx() function. Unfortunately, starting with VapourSynth r49, we don't even get to that point! There now seems to be a "static" dependency of 'vsscript.dll' to 'python38.dll', so that the Windows loader fails to load/run the 'vspipe.exe' at all...

Never mind. Forgot to change the linker flag to delay load python38.dll instead of the 37 one. Expect R50 to be release within a week with some other mixed fixes.

[Patman]

I have Python 3.8 installed globally, for all users (customized installation).

The problem is that 'vspipe.exe' depends 'vsscript.dll', which in turn depends on 'python38.dll'. The dependency of 'vspipe.exe' to 'vsscript.dll' is no problem at all, as they both reside in the same directory (VapurSynth install directory). However, the 'python38.dll' resides in the separate Python 3.8 install directory, which can not be assumed to be on PATH, or any other directory that Windows searches for DLLs by default.

Now, there actually is code in the vsscript_init() function in 'vsscript.dll' that will determine the path of Python from the registry and explicitly load 'python38.dll' via LoadLibraryEx() function. Unfortunately, starting with VapourSynth r49, we don't even get to that point! There now seems to be a "static" dependency of 'vsscript.dll' to 'python38.dll', so that the Windows loader fails to load/run the 'vspipe.exe' at all...

Yes you are right. I tested it again and if you don't add Python to the path, vspipe will return a bug like yours. You have to pay attention to the little things ;) :thanks:

[LoRd_MuldeR]

Never mind. Forgot to change the linker flag to delay load python38.dll instead of the 37 one. Expect R50 to be release within a week with some other mixed fixes.

:thanks:

[feisty2]

if a python function is passed to a filter as an argument, and is invoked in the filter via callFunc, is the return value of the function always associated with "val" key in the output map? what happens if the python function returns multiple values, especially multiple values of different types?

[Myrsloik]

if a python function is passed to a filter as an argument, and is invoked in the filter via callFunc, is the return value of the function always associated with "val" key in the output map? what happens if the python function returns multiple values, especially multiple values of different types?

It has to follow the required form of the function as specified by the filter you pass it to. The return value always has to be convertible to a VSMap or callFunc fails so returning different types isn't possible.

[lansing]

What is the fastest way to create a video with a still image? Something like with blankclip where we can specify the length and frame rate of the clip?

[Lypheo]

If I’m getting this right and you want to extend a single frame clip by repetition, just use the * operator, e.g.: src = core.imwri.Read(…) * 10000

[_Al_]

or to assume desired frame rate if needed, but it might be specified by imwri, don't know now
src = core.std.AssumeFPS(clip=src, fpsnum=30000, fpsden=1001)
but I think you know that,
Not sure what would be another way to load an image in a simple manner. Like using numpy and opencv or PIL together with ModifyFrame and placeholder clip (attribute clip). That seems like much longer procedure (for RGB image).

[lansing]

If I’m getting this right and you want to extend a single frame clip by repetition, just use the * operator, e.g.: src = core.imwri.Read(…) * 10000

Thanks, this solution seems good enough

[Myrsloik]

R50-RC1 (https://github.com/vapoursynth/vapoursynth/releases/tag/R50-RC1). It's a pure bugfix release so if you use R48 or R49 you should definitely give it a try.
r50:
updated zimg to latest v2.9 so grayscale colorspace are supported
fixed crash in textfilter line wrapping introduced in r49 (sekrit-twc)
fixed regression introduced in r48 where sobel and prewitt wouldn't clamp 9-15 bit output to valid range (sekrit-twc)
fixed crash due to null pointer dereference when instantiation many vapoursynth classes directly in python
fixed regression in r49 where the python dll could only be located when in the PATH on windows

[tuanden0]

R50-RC1 (https://github.com/vapoursynth/vapoursynth/releases/tag/R50-RC1). It's a pure bugfix release so if you use R48 or R49 you should definitely give it a try.
r50:
updated zimg to latest v2.9 so grayscale colorspace are supported
fixed crash in textfilter line wrapping introduced in r49 (sekrit-twc)
fixed regression introduced in r48 where sobel and prewitt wouldn't clamp 9-15 bit output to valid range (sekrit-twc)
fixed crash due to null pointer dereference when instantiation many vapoursynth classes directly in python
fixed regression in r49 where the python dll could only be located when in the PATH on windows

It still show R49 instead of 50
→ C:\Users\Home› vspipe --version
VapourSynth Video Processing Library
Copyright (c) 2012-2020 Fredrik Mellbin
Core R49
API R3.6
Options: -

[HuBandiT]

Greetings,

I noticed that when I AverageFrames() a clip in vs.RGBS format, when weights[] is longer than the documented - but not enforced - maximum of 31, AverageFrames() darkens the result - the longer weights[] is, the more darkening.

I am on x86.

Looking at the source I see averageFramesFloatSSE2() computes the weighted sum of only 31 frames, but then - incorrectly - multiplies the result with the scale computed for the entire weights[] array.

Desired result #1 (preferred): allow arbitrary length averaging. (I hope for this, because this is the only codepath where I saw this 31 hardcoded - the others might actually allow unlimited?)

Desired result #2 (not preferred): prevent incorrect usage by giving a hard error message

Rationale: I am working on modernizing "talking head" type of instructional videos from DVD MPEG-2, with lots of static background (for minutes), where it would not be unreasonable to frame average the background areas over 5-10 seconds to attempt to average out camera photon noise distorted by MPEG-2. The source is 50i PAL, I deinterlace it to 50p, then comes the noise reduction. But 31 frames is limiting, since at 50p coming from 50i it is about 15-16 original interlaced frames, which is about the length of a single GOP so this precludes me from averaging over GOPs, also it is only about 0.6 seconds. When I diff the resulting frames, even truncated to 8 bit depth, I still have too many artifacts.

Thank you in advance. VapourSynth is awesome.

PS: For this type of filtering, I always use "weights = [1] * number", so a performance optimization could be to omit the multiplications when all the weights are equal and factor them into the scaler.

[Myrsloik]

Greetings,

I noticed that when I AverageFrames() a clip in vs.RGBS format, when weights[] is longer than the documented - but not enforced - maximum of 31, AverageFrames() darkens the result - the longer weights[] is, the more darkening.

I am on x86.

Looking at the source I see averageFramesFloatSSE2() computes the weighted sum of only 31 frames, but then - incorrectly - multiplies the result with the scale computed for the entire weights[] array.

Desired result #1 (preferred): allow arbitrary length averaging. (I hope for this, because this is the only codepath where I saw this 31 hardcoded - the others might actually allow unlimited?)

Desired result #2 (not preferred): prevent incorrect usage by giving a hard error message

Rationale: I am working on modernizing "talking head" type of instructional videos from DVD MPEG-2, with lots of static background (for minutes), where it would not be unreasonable to frame average the background areas over 5-10 seconds to attempt to average out camera photon noise distorted by MPEG-2. The source is 50i PAL, I deinterlace it to 50p, then comes the noise reduction. But 31 frames is limiting, since at 50p coming from 50i it is about 15-16 original interlaced frames, which is about the length of a single GOP so this precludes me from averaging over GOPs, also it is only about 0.6 seconds. When I diff the resulting frames, even truncated to 8 bit depth, I still have too many artifacts.

Thank you in advance. VapourSynth is awesome.

PS: For this type of filtering, I always use "weights = [1] * number", so a performance optimization could be to omit the multiplications when all the weights are equal and factor them into the scaler.

Doh, found the typo in the weights check so please verify that it's really fixed in the next RC.

Arbitrary length averaging will never be supported because for float you'll at some point accumulate a huge rounding error or for integer formats you'll overflow.

If you need longer averaging you can simply do something like clip.misc.AverageFrames(weights=[1]*31)[::31].misc.AverageFrames(weights=[1]*31)

The multiply is probably so fast it doesn't matter compared to all the memory access.

[HuBandiT]

Doh, found the typo in the weights check so please verify that it's really fixed in the next RC.

Thank you, will do.

Arbitrary length averaging will never be supported because for float you'll at some point accumulate a huge rounding error or for integer formats you'll overflow.

Indeed, I did not actually mean "arbitrary". But maybe a higher than the current 31 frame limit then? At least for higher precision formats? Maybe set the limit based on some analysis of the numerical precision of the format chosen? 32 bit float RGBS has a 24 bit significand. Reserving two bits from those 24 for the 4.5 multiplier near the foot of rec.601/rec.709, I have about 22 bits of linear precision left. So when I target rec.709 YUV420P8, YUV420P10 or YUV420P12, I have 22-8=14, 22-10=12, 22-12=10 bits of headroom in precision before rounding errors show up in the output; it seems that even in the worst case I could use those bits to average 2^14=16384, 2^12=4096 and 2^10=1024 frames respectively? The current 31 frame limit limits me to use only 5 of those extra bits meaningfully, leaving me with 9, 7 and 5 "unusable" bits of headroom.

The multiply is probably so fast it doesn't matter compared to all the memory access.

The very point is reducing memory access: if all the weights are the same (and with integer formats - although it probably will also work just well enough with floats on real material), you could simply update the running average by subtracting the sample falling out the window and adding the sample newly entering the window, instead of calculating the entire sum from scratch anew each time; in fact one could just add the difference between the falling out sample and the newly entering sample, to be one small step farther away from overflow. Not frame parallelizable for sure (although it would be parallelizable spatially with frame slices), but it might still end up being a huge win for long averages because of the drastically reduced memory access from O(n) to about O(4): read from 2 source frames, read/modify/store the running average; and should the internal running average use higher precision - say double for float inputs, or 32 bit integer for 16 bit inputs, which might make sense - finally downconverting the running average into the desired output precision. Not great for simplistic benchmarks perhaps, but my hunch is that if there is any meaningfully heavy processing happening after the average, the runtime contribution of the averaging operation will be negligible compared to that. It would be nice to at least have the option.

If you need longer averaging you can simply do something like clip.misc.AverageFrames(weights=[1]*31)[::31].misc.AverageFrames(weights=[1]*31)

Yes, I, too, was pondering a hierarchical approach like this. I'll have think about this, as at first sight I don't think it would give equivalent results. Plus boundary issues (scene detection).

[Myrsloik]

You do have a point with most things but that's an extremely specialized filter. Feel free to write it.

In regards to the bits of headroom you kinda want a general filter to be able to support equivalent settings for all formats. It simply makes sense for the users. That's why the limit is 31 frames. At some point all the ifs and buts of a filter become too complicated.

[HuBandiT]

You do have a point with most things but that's an extremely specialized filter. Feel free to write it.

Alright. Pointers to how to write VapourSynth filters in C++ are welcome. Also how to decide on a namespace? Can I piggyback onto an existing namespace, or do I need to pick a separate one?

In regards to the bits of headroom you kinda want a general filter to be able to support equivalent settings for all formats. It simply makes sense for the users. That's why the limit is 31 frames. At some point all the ifs and buts of a filter become too complicated.

I don't think this is conceptually different from, say, the limitations of the crop filters: they do have limitations based on the format: subsampled formats can only be cropped by multiples of the subsampling factors; otherwise things would get difficult - but when there is no subsampling, the limitations don't apply, so not enforced.

[feisty2]

Alright. Pointers to how to write VapourSynth filters in C++ are welcome. Also how to decide on a namespace? Can I piggyback onto an existing namespace, or do I need to pick a separate one?


you could take a look at vsFilterScript if ur compiler supports most of C++20 core language features, it is the easiest way to get started.

the namespace must be unique, you must define ur own namespace.

[LoRd_MuldeR]

r50:
fixed regression in r49 where the python dll could only be located when in the PATH on windows

I can confirm it's fixed now. Thanks!

[HuBandiT]

you could take a look at vsFilterScript if ur compiler supports most of C++20 core language features, it is the easiest way to get started.

the namespace must be unique, you must define ur own namespace.

Thank you, I started doing my own thing from scratch to practice some C++, I took a short look at yours, but I'll look more closely later. It does look very script-y though. :D

[Myrsloik]

R50-RC2 (https://github.com/vapoursynth/vapoursynth/releases/tag/R50-RC2)

r50:
updated zimg to latest v2.9 so grayscale colorspace are supported
added __version__ and __api_version__ to python module to make detecting version mismatches easier
improved rounding in averageframes (sekrit-twc)
fixed averageframes not properly rejecting more than 31 weights or nodes
fixed crash in textfilter line wrapping introduced in r49 (sekrit-twc)
fixed regression introduced in r48 where expr, sobel and prewitt wouldn't clamp 9-15 bit output to valid range (sekrit-twc)
fixed crash due to null pointer dereference when instantiation many vapoursynth classes directly in python
fixed regression in r49 where the python dll could only be located when in the PATH on windows

If someone on linux can confirm or deny this bug https://github.com/vapoursynth/vapoursynth/issues/503 it'd be helpful.

[l33tmeatwad]

If I could make a recommendation, it would be nice if the Linux setup automatically detected if dist-packages exists and then use that instead of site-packages considering Debian based Linux distros and a few others use that instead of site-packages for Python. Either that or updating the current guide on the main site to recommend checking for that and creating a symbolic link to redirect files from site-packages to dist-packages would be nice considering this affects quite a few popular Linux distros, such as Ubuntu. Side note, most of the distros that have that issue also need the end user to run ldconfig or it will fail to load as well so it would be nice to include that in the documentation as well.

[HuBandiT]

Low priority question:

Is queryCompletedFrame() still "This function has several issues and may or may not return the actual node or frame number."? Even in an fmSerial filter?

If yes, how much work would be needed to fix it? (Or is there another way to query the new frame when VSFilterGetFrame() is called with arFrameReady?)

[Myrsloik]

Low priority question:

Is queryCompletedFrame() still "This function has several issues and may or may not return the actual node or frame number."? Even in an fmSerial filter?

If yes, how much work would be needed to fix it? (Or is there another way to query the new frame when VSFilterGetFrame() is called with arFrameReady?)

The frame number is always correct in more recent versions. It's just the node pointer you can't trust. Modes and other things have nothing to do with it and change nothing.

This much work needed to fix it:
|--------------------|

[Myrsloik]

R50 is released. Bug fixes only so everyone should update.
r50:
updated zimg to latest v2.9 so grayscale colorspace are supported
fixed several minor issues related to path handling in vsrepo
added __version__ and __api_version__ to python module to make detecting version mismatches easier
improved rounding in averageframes (sekrit-twc)
fixed averageframes not properly rejecting more than 31 weights or nodes
fixed crash in textfilter line wrapping introduced in r49 (sekrit-twc)
fixed regression introduced in r48 where expr, sobel and prewitt wouldn't clamp 9-15 bit output to valid range (sekrit-twc)
fixed crash due to null pointer dereference when instantiation many vapoursynth classes directly in python
fixed regression in r49 where the python dll could only be located when in the PATH on windows

[Boulder]

Thank you for the new release :)

[Txico]

Hello there.
Last time I posted here was in august because I had trouble with the environment variables, python 3.7 and Ubuntu. Gladly solved.
Now Ubuntu 20.04 is out and I'm not any longer capable of compiling the sources to build.
After installing all the packages in the documentation for Linux compilation I got through the ./autogen.sh and ./configure, but now make give me this error:
CXXLD vspipe
/usr/bin/ld: ./.libs/libvapoursynth-script.so: undefined reference to `Py_InitializeEx'
/usr/bin/ld: ./.libs/libvapoursynth-script.so: undefined reference to `PyDict_GetItemString'
/usr/bin/ld: ./.libs/libvapoursynth-script.so: undefined reference to `PyObject_GetAttrString'
/usr/bin/ld: ./.libs/libvapoursynth-script.so: undefined reference to `_Py_Dealloc'
/usr/bin/ld: ./.libs/libvapoursynth-script.so: undefined reference to `PyImport_ImportModule'
/usr/bin/ld: ./.libs/libvapoursynth-script.so: undefined reference to `PyCapsule_GetPointer'
/usr/bin/ld: ./.libs/libvapoursynth-script.so: undefined reference to `PyCapsule_IsValid'
/usr/bin/ld: ./.libs/libvapoursynth-script.so: undefined reference to `PyEval_SaveThread'
/usr/bin/ld: ./.libs/libvapoursynth-script.so: undefined reference to `PyGILState_Ensure'
/usr/bin/ld: ./.libs/libvapoursynth-script.so: undefined reference to `Py_IsInitialized'
collect2: error: ld returned 1 exit status
make: *** [Makefile:1318: vspipe] Error 1

At least the first error, the one with Py_InitializeEx, I get is threads related. But I don't know what I'm missing and documentation doesn't give me any clue.
Anybody? Please?

[jackoneill]

Hello there.
Last time I posted here was in august because I had trouble with the environment variables, python 3.7 and Ubuntu. Gladly solved.
Now Ubuntu 20.04 is out and I'm not any longer capable of compiling the sources to build.
After installing all the packages in the documentation for Linux compilation I got through the ./autogen.sh and ./configure, but now make give me this error:
CXXLD vspipe
/usr/bin/ld: ./.libs/libvapoursynth-script.so: undefined reference to `Py_InitializeEx'
/usr/bin/ld: ./.libs/libvapoursynth-script.so: undefined reference to `PyDict_GetItemString'
/usr/bin/ld: ./.libs/libvapoursynth-script.so: undefined reference to `PyObject_GetAttrString'
/usr/bin/ld: ./.libs/libvapoursynth-script.so: undefined reference to `_Py_Dealloc'
/usr/bin/ld: ./.libs/libvapoursynth-script.so: undefined reference to `PyImport_ImportModule'
/usr/bin/ld: ./.libs/libvapoursynth-script.so: undefined reference to `PyCapsule_GetPointer'
/usr/bin/ld: ./.libs/libvapoursynth-script.so: undefined reference to `PyCapsule_IsValid'
/usr/bin/ld: ./.libs/libvapoursynth-script.so: undefined reference to `PyEval_SaveThread'
/usr/bin/ld: ./.libs/libvapoursynth-script.so: undefined reference to `PyGILState_Ensure'
/usr/bin/ld: ./.libs/libvapoursynth-script.so: undefined reference to `Py_IsInitialized'
collect2: error: ld returned 1 exit status
make: *** [Makefile:1318: vspipe] Error 1

At least the first error, the one with Py_InitializeEx, I get is threads related. But I don't know what I'm missing and documentation doesn't give me any clue.
Anybody? Please?

It's because of a change in Python 3.8, but this is supposed to work now with VapourSynth R50. What version are you trying to compile?

A temporary solution is to run make again like this:

make LIBS="$(python3-config --libs --embed)"

(It has nothing to do with threads.)

[Txico]

Thanks a lot! That did the trick. And thanks for the quick response.
I was trying to compile the latest release R50, now it works.
I know it was nothing related to threads. It was related to standard libraries not been found, but I didn't know how to solved it.
An official documentation update could be really nice ...

[Txico]

And now I'm having trouble loading plug-ins ...
I tried to set the UserPluginDir variable on compile time with "configure --with-plugindir='/home/myuser/vapoursynth-plugins'", creating a vapoursynth.conf file with "UserPluginDir=/home/myuser/vapoursynth-plugins" and setting an incorrect value for the folders or change the name folder: Autoloading the user plugin dir '/home/myuser/vapoursynth-plugins' failed. Directory doesn't exist?
So the variable is working.
So, why I'm having trouble doing something as easy as "import havsfunc as haf" when the file havsfunc.py is there?
ModuleNotFoundError: No module named 'havsfunc'

Any clue? Anything else I need to know?

[Are_]

Because .py files are not plugins but python modules. You need to place them inside your root protected site-packages directory (ore whatever is called in your distro).

If you don't want to mess with that you can create a .pth file there with the path to de directory you want to put your python modules inside. Like for example:
$ cat /usr/lib64/python3.6/site-packages/vapoursynth-autoload.pth
/home/youruser/vapoursynth-python-modules

[Selur]

@Txico: you can also do something like:
# Import scripts folder
scriptPath = '/home/myuser/vapoursynth-scripts'
sys.path.append(os.path.abspath(scriptPath))
to allow "import havsfunc as haf" when the havsfunc.py is inside the '/home/myuser/vapoursynth-scripts' folder.
Note that this will not automatically import the libraries,...

---
@all: are there any Intel® Open Image Denoise filters for Vapoursynth out there?

[ChaosKing]

Lets talk again about this problem here https://forum.doom9.org/showthread.php?p=1840996#post1840996

I'm now very sure that this problem is in some way connected to FrameEval()

Problem: Functions with a high temporal radius (called by frameEval) produces different results then without FrameEval
https://i.imgur.com/gLvGYsY.gif

I don't think that all 4 plugins are storing temporal state incorrectly.

Example script:
import functools
import vapoursynth as vs
import mvsfunc as mvf #https://github.com/HomeOfVapourSynthEvolution/mvsfunc/blob/master/mvsfunc.py

core = vs.get_core()

def comp(a, b, crop=0):
return core.std.StackHorizontal([
core.std.CropRel(a, crop,crop,0,0), \
core.std.CropRel(b, crop,crop,0,0), \
])


# Goal here is to remove dynamic grain and replace it with similar static grain
def ReGrainDenoise(clip):
# test denoiser 1
#clip = mvf.Depth(clip, 32)
#sup = core.mvsf.Super(clip)
#vec = core.mvsf.Analyze(sup, radius=9, overlap=4)
#vec = core.mvsf.Recalculate(sup, vec, blksize=4, overlap=2)
#denoised = core.mvsf.Degrain(clip, sup, vec, thsad=1600)

# test denoiser 2
#import havsfunc as haf #https://github.com/HomeOfVapourSynthEvolution/mvsfunc/blob/master/mvsfunc.py
#clip = mvf.Depth(clip, 16)
#denoised = haf.SMDegrain(clip, tr=3, thSAD=1500)
#denoised = denoised.flux.SmoothST( temporal_threshold=16, spatial_threshold=16)
#denoised = mvf.Depth(denoised, 32)
#clip = mvf.Depth(clip, 32)

# test denoiser 3
##lip = mvf.Depth(clip, 16)
#denoised = clip.knlm.KNLMeansCL(d=8, h=6)
#denoised = mvf.Depth(denoised, 32)
#clip = mvf.Depth(clip, 32)

# test "denoiser" 4
denoised = clip.misc.AverageFrames(weights=[1]*31)[::31].misc.AverageFrames(weights=[1]*31)

# add back static grain
grain = denoised.grain.Add(var=1200.0, constant=True)
diff_clip = core.std.Expr([clip, denoised], 'x y - abs').std.Inflate(threshold=200/255).std.Inflate(threshold=200/255)
mask_clip = diff_clip.std.Binarize(threshold=[3.3/219, 3.3/224], v0=0, v1=80/255)
clip = core.std.MaskedMerge(clipa=denoised, clipb=grain, mask=mask_clip)

return mvf.Depth(clip, 32)



clip = core.std.BlankClip(format=vs.YUV420P16, width=120*2, height=80*2, length=100, color=[206,235,135])
clip = mvf.Depth(clip, 32)
clip = clip.grain.Add(var=100.0, constant=False)
orig=clip


def CalledbyFrameEval(n, c):
return ReGrainDenoise(c)

WithFrameEval = clip.std.FrameEval(functools.partial(CalledbyFrameEval, c=clip))
NoFrameEval = ReGrainDenoise(clip)

clip = comp(
WithFrameEval.text.Text("called from FrameEval").std.AddBorders(right=2),
NoFrameEval.text.Text("Without FrameEval").std.AddBorders(right=2), crop=0
)
clip = comp(clip, orig.text.Text("unfiltered"), crop=0)

clip.set_output()

EDIT: Added AverageFrames() as "denoiser"

[feisty2]

I have 2 questions regarding the API

1) what kind of filter outputs multiple clips, and what is the python syntax to bind the outputs of such filter?
is it

clips = core.???.filter(...)
#clips[0], clips[1], ...

or

clip1, clip2, ... = core.???.filter(...)

?

2) does audio support break compatibility with the current API? where can I find the audio API?

[Myrsloik]

I have 2 questions regarding the API

1) what kind of filter outputs multiple clips, and what is the python syntax to bind the outputs of such filter?
is it

clips = core.???.filter(...)
#clips[0], clips[1], ...

or

clip1, clip2, ... = core.???.filter(...)

?

2) does audio support break compatibility with the current API? where can I find the audio API?

1. It returns a list of clips so your first guess is used.
2. Audio support doesn't break the API at all, simply extends it. You can find it in the doodle1 branch. Expect a new test release in a few days when I finish writing and testing a few more simple audio filters.

[HuBandiT]

What is the problem you are trying to solve?

Do you really need FrameEval() for it?

Also, why are you denoising in YUV space? Your result will look blurry.

[feisty2]

why does vspipe freeze then crash if I comment out this line (https://github.com/IFeelBloated/vsFilterScript/blob/master/Examples/ModifyFrame.hxx#L7) (which assumes the default multithreading mode, fmParallel (https://github.com/IFeelBloated/vsFilterScript/blob/master/include/Interface.vxx#L36))?

the default multithreading mode however seems to work with vsedit (preview)

[Myrsloik]

why does vspipe freeze then crash if I comment out this line (https://github.com/IFeelBloated/vsFilterScript/blob/master/Examples/ModifyFrame.hxx#L7) (which assumes the default multithreading mode, fmParallel (https://github.com/IFeelBloated/vsFilterScript/blob/master/include/Interface.vxx#L36))?

the default multithreading mode however seems to work with vsedit (preview)

Does this require a C++20 comoiler to test?

[feisty2]

Does this require a C++20 comoiler to test?

yes, GCC10 is required to compile this thing, I guess clang10 should also work. However I believe this problem could be reproduced with the C API as well, since I copied this parallel request mode from the core code base (https://github.com/vapoursynth/vapoursynth/blob/master/src/core/simplefilters.c#L1718).

[ortoni]

Getting an odd compilation error Cython compiling vapoursynth.c during vapoursynth make:
Error compiling Cython file:
------------------------------------------------------------
...
def keys(self):
cdef const VSMap *m = self.funcs.getFramePropsRO(self.constf)
cdef int numkeys = self.funcs.propNumKeys(m)
result = set()
for i in range(numkeys):
set.add(self.funcs.propGetKey(m, i).decode('utf-8'))
^
------------------------------------------------------------

src/cython/vapoursynth.pyx:1095:19: Call with wrong number of arguments (expected 2, got 1)
make: *** [Makefile:2368: src/cython/vapoursynth.c] Error 1

Ubuntu 20.04 on Windows Linux Subsystem, did a pip3 install cython: Successfully installed cython-0.29.19
added /home/<username>/.local/bin to $PATH, all the usual stuff.

Any ideas/ further information needed? I successfully installed on Native Ubuntu 19.10 a while back and updated to 20.04; all still A-OK there.
TIA

[Myrsloik]

Getting an odd compilation error Cython compiling vapoursynth.c during vapoursynth make:
Error compiling Cython file:
------------------------------------------------------------
...
def keys(self):
cdef const VSMap *m = self.funcs.getFramePropsRO(self.constf)
cdef int numkeys = self.funcs.propNumKeys(m)
result = set()
for i in range(numkeys):
set.add(self.funcs.propGetKey(m, i).decode('utf-8'))
^
------------------------------------------------------------

src/cython/vapoursynth.pyx:1095:19: Call with wrong number of arguments (expected 2, got 1)
make: *** [Makefile:2368: src/cython/vapoursynth.c] Error 1

Ubuntu 20.04 on Windows Linux Subsystem, did a pip3 install cython: Successfully installed cython-0.29.19
added /home/<username>/.local/bin to $PATH, all the usual stuff.

Any ideas/ further information needed? I successfully installed on Native Ubuntu 19.10 a while back and updated to 20.04; all still A-OK there.
TIA

Update to latest master and try again. And specify that it's master you're compiling next time.