Vapoursynth

[tuanden0]

Originally Posted by Myrsloik

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]

Originally Posted by 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.

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]

Originally Posted by Myrsloik

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

Thank you, will do.

Originally Posted by Myrsloik

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.

Originally Posted by Myrsloik

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.

Originally Posted by Myrsloik

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]

Originally Posted by Myrsloik

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?

Originally Posted by Myrsloik

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]

Originally Posted by HuBandiT

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]

Originally Posted by Myrsloik

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]

Originally Posted by feisty2

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.

[Myrsloik]

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]

Originally Posted by 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?)

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]

Originally Posted by 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?

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