Vapoursynth

[Exaris]

I am getting a "Failed to initialize VapourSynth" error whenever I try to use it. Where can I get a more verbose log?

Vapoursynth: VapourSynth 64bit (R50 final)
Frontend: StaxRip (2.1.3.0)
Python: Python 3.8.4 64bit (build 3.8.4150.1013)
OS: Windows 10 Pro 1909 64bit (build 18363.836)

Best available "log":

------------------------ Error opening source ------------------------

Failed to initialize VapourSynth

import os, sys
import vapoursynth as vs
core = vs.get_core()
sys.path.append(r"C:\Users\Dante\Desktop\Random\Util\StaxRip-2.1.3.0\Apps\Plugins\VS\Scripts")
core.std.LoadPlugin(r"C:\Users\Dante\Desktop\Random\Util\StaxRip-2.1.3.0\Apps\Support\DGDecodeNV\DGDecodeNV.dll")
clip = core.dgdecodenv.DGSource(r"G:\2020-07-14 17-14-06_temp\2020-07-14 17-14-06.dgi")
clip.set_output()

P.S. This crash occurs with any source (LibavSMASHSource/LWLibavsource/DGDecodeNV)

[stax76]

This message shows when vsscript_init fails which probably means that vapoursynth does generally not work.

Is VapourSynth is installed, for all or current user, in which location?

Portable mode is disabled in the staxrip settings? (it's enabled by default)

Does the script open in other apps such as VirtualDub2, MPC-BE or VapourSynth Editor?

[Exaris]

I've uninstalled Vapoursynth and enabled the use of the portable version but the problem persists.
If by "the script" you mean the .vpy file in the _temp folder then yes, MPC-BE plays it just fine.

[stax76]

The VapourSynth docs on vsscript_init:

This function will only fail if the VapourSynth installation is broken in some way.

Please try the last Beta StaxRip 2.1.3.7.

If portable mode is enabled in the settings then the paths in the Apps dialog for VapourSynth and Python should both point to Apps\FrameServer\VapourSynth.

Maybe just a runtime is missing, here is an all-in-one package:

https://github.com/abbodi1406/vcredist/releases/tag/v0.33.0

[Exaris]

I've just tried the beta, same problem.

Portable mode is enabled and pointing to Apps\FrameServer\VapourSynth.

I installed that repack and its still not working.

Also MPC-BE plays the .vpy in _temp perfectly as well.

[Myrsloik]

I'm not dead, just working on the next big api version. Proper graph dumping included.
https://www.dropbox.com/s/k6m0uxfy9lnn4j6/graphviz.svg?dl=0

[vcmohan]

In one of the functions of my plugin I return a frame of same input format but having different width and height, as in stack horizontal or any resize filter. I get a new frame of these dimensions, but I think I should not return this as subsequent filters will be unaware. Where can I look at the source code of resize to learn the coding required. As vi is a const I am prevented to change it.

[Myrsloik]

In one of the functions of my plugin I return a frame of same input format but having different width and height, as in stack horizontal or any resize filter. I get a new frame of these dimensions, but I think I should not return this as subsequent filters will be unaware. Where can I look at the source code of resize to learn the coding required. As vi is a const I am prevented to change it.

It's only the vi of existing clips that's const. You can create a copy and modify it any way you want like in the stackhorizontal/vertical filter.

https://github.com/vapoursynth/vapoursynth/blob/master/src/core/simplefilters.c#L1143

[Myrsloik]

Usage question of the day:

Does anyone actually use the --start and --end arguments of vspipe?

[DJATOM]

Yes, but rare. It was good for partial renders when I was lazy to copy script with different trims and just made a list of commands with different -s -e options and output names.

[zorr]

Usage question of the day:

Does anyone actually use the --start and --end arguments of vspipe?

Yes. I need them on some scripts which are not utilizing the cores efficiently. So I split the clip into ranges and run them simultaneously and combine the parts in the end. This can be up to 12 times faster than running the script as is (Ryzen 3900X).

[stax76]

Does anyone actually use the --start and --end arguments of vspipe?

The chunk encoding feature of staxrip uses it.

https://staxrip.readthedocs.io/usage.html#chunk-encoding

[ChaosKing]

I use it sometimes too.

[vcmohan]

Is there an equivalent of avisynth scriptclip in vapoursynth? How does one get current frame number in scripting?

[ChaosKing]

Is there an equivalent of avisynth scriptclip in vapoursynth? How does one get current frame number in scripting?

http://www.vapoursynth.com/doc/functions/frameeval.html


import functools
def MyFunc(n, c):
if (n % 2) == 0:
return c.text.Text("Frame: " + str(n))
else:
return c.text.Text("Frame: " + str(n)).text.Text("\nThats odd...")

clip = core.std.FrameEval(clip, functools.partial(MyFunc, c=clip))

[Myrsloik]

You have successfully saved the --start and --end arguments then.

Now for the new vspipe experiment of the day. How many of your scripts would break if --preserve-cwd was made the default option?

[ChaosKing]

Looks like zero breaks for me.

[zorr]

Couldn't find anything with --preserve-cwd. What is it?

[ChaosKing]

cwd = current working dir

[Myrsloik]

R51-RC1 (https://github.com/vapoursynth/vapoursynth/releases/tag/R51-RC1)
This should be a quick release process. Only bug fixes this time (and probably forever until the glorious audio branch is ready)
r51:
updated visual studio 2019 runtime version
fixed an extremely rare threading issue only affecting fmparallelrequests filters and arframeready events
fixed compilation when avs+ master is used
fixed lut and lut2 triggering a fatal error when invalid planes were specified
fixed property append operations on non-empty keys not properly copying the underlying data
fixed wave64 headers generated by avfs
fixed crash in averageframes with odd number of clips (sekrit-twc)
scale averageframes for integer chroma by distance from grey (sekrit-twc)
several fixes and improvements regarding handling of the active script environment in python (stuxcrystal)
plugin loading now has better error messages (jackoneill)
using get_core() in python now generates a deprecation warning since it's been deprecated for years

[feisty2]

r51:
using get_core() in python now generates a deprecation warning since it's been deprecated for years

how do I specify constants like vs.GRAY or vs.RGB if I switch

import vapoursynth as vs
core = vs.get_core()


to


from vapoursynth import core


?

[ChaosKing]

You can use this from vapoursynth import core, YUV, GRAY and then use just GRAY instead of vs.GRAY
OR

use core = vs.core instead of core = vs.get_core()

EDIT
whoops I was too slow :)

[feisty2]

is there any filter that actually uses VSActivationReason::arFrameReady and queryCompletedFrame()? I haven't been able to find any example for this

[Myrsloik]

is there any filter that actually uses VSActivationReason::arFrameReady and queryCompletedFrame()? I haven't been able to find any example for this

Not that I know of. I'm thinking about removing it completely for the next api revision since I couldn't think of a single useful filter that needs it.

QueryCompletedFrame is also half broken...

[Myrsloik]

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

Found a few more trivially fixable bugs when developing the glorious new branch. So here's another RC. If you have far too much time on your hands you could compare the speed and memory usage with R50.

Changes
r51:
updated visual studio 2019 runtime version
fixed a cache shrinking issue
fixed a crash when removing a message handler without a free function
fixed an extremely rare threading issue only affecting fmparallelrequests filters and arframeready events
fixed compilation when avs+ master is used
fixed lut and lut2 triggering a fatal error when invalid planes were specified
fixed property append operations on non-empty keys not properly copying the underlying data
fixed wave64 headers generated by avfs
fixed crash in averageframes with odd number of clips (sekrit-twc)
scale averageframes for integer chroma by distance from grey (sekrit-twc)
several fixes and improvements regarding handling of the active script environment in python (stuxcrystal)
plugin loading now has better error messages (jackoneill)
using get_core() in python now generates a deprecation warning since it's been deprecated for years

[HuBandiT]

is there any filter that actually uses VSActivationReason::arFrameReady and queryCompletedFrame()? I haven't been able to find any example for this

Not that I know of. I'm thinking about removing it completely for the next api revision since I couldn't think of a single useful filter that needs it.

QueryCompletedFrame is also half broken...

A few years ago there was talk about potentially getting GPUs involved into VS and VS filters, at which point it might suddenly make sense to hide RAM->GPU transfer latencies by initiating transfer of each individual incoming frame as soon as it becomes available (arFrameReady), instead of initiating transfer of all frames in one large batch (arAllFramesReady). The same would hold in the hypothetical case of writing a multi-node distribution layer for VS (think renderfarm for video filtering).

[Myrsloik]

A few years ago there was talk about potentially getting GPUs involved into VS and VS filters, at which point it might suddenly make sense to hide RAM->GPU transfer latencies by initiating transfer of each individual incoming frame as soon as it becomes available (arFrameReady), instead of initiating transfer of all frames in one large batch (arAllFramesReady).

GPUs are kinda dead in this space. You can get 64 cores in a single socket UMA configuration for almost nothing now. I plan to focus on making things run as well as possible with many threads.

You also don't need arFrameReady events unless your filter implementation is a monolithic monstrosity. Have a separate filter to do transfers to the GPU an one after processing to transfer back if needed. That's more or less how I'd handle GPU support if I ever officially added it anyway.

[HuBandiT]

Purely academic as I agree it is not worth pursuing this for now:

GPUs are kinda dead in this space. You can get 64 cores in a single socket UMA configuration for almost nothing now. I plan to focus on making things run as well as possible with many threads.

Processing paralellism (cores) yes - but memory paralellism...? Plus you do tie up your CPUs while leaving your GPUs idle, which might be a factor for certain workloads.

You also don't need arFrameReady events unless your filter implementation is a monolithic monstrosity. Have a separate filter to do transfers to the GPU an one after processing to transfer back if needed. That's more or less how I'd handle GPU support if I ever officially added it anyway.

For a very forward-looking discussion: OpenCV went through similar CPU memory <-> GPU memory teething pains some years back, and as I recall, they decided to go for making the core (built-in) image structure/class/type/object aware of in which memory domain (CPU or GPU - and for that matter, which GPU if there are several) it currently resides on or has copies in, and having both CPU and GPU versions of most built-in filters, so that transfers between memory domains could be elided in many cases. (Not sure how far they went on optimizing those filter graphs, whether that was statically decided by the programmer, or dynamically optimized during runtime, etc.)

[Myrsloik]

CPUs with more cores have more memory channels and bandwidth too. Unless it's a crippled server cpu being sold to enthusiasts.

The current filter model of operating on whole frames is also very memory bandwidth inefficient. Adding support for filters that work per scanline/tile will allow for huge improvements since then L3 and L2 cache speed would be the limit and not ram.

It's it's the curse of having a simple and developer friendly filter model.

Writing two versions of filters, even the basic ones, is unsustainable for a project of this size. And I don't only mean in terms of development time but also the number of users that test things. It would most likely constantly end up broken.

[Cary Knoop]

CPUs with more cores have more memory channels and bandwidth too. Unless it's a crippled server cpu being sold to enthusiasts.

The current filter model of operating on whole frames is also very memory bandwidth inefficient. Adding support for filters that work per scanline/tile will allow for huge improvements since then L3 and L2 cache speed would be the limit and not ram.

It's it's the curse of having a simple and developer friendly filter model.

Writing two versions of filters, even the basic ones, is unsustainable for a project of this size. And I don't only mean in terms of development time but also the number of users that test things. It would most likely constantly end up broken.
Or, have an interface that allows CUDA filters using a CUDA source file that gets compiled on Vapoursynth invocation?


DaVinci Resolve uses this model, you can write a CUDA file with a given interface like so:

__DEVICE__ float3 transform(int p_Width, int p_Height, int p_X, int p_Y, __TEXTURE__ p_TexR, __TEXTURE__ p_TexG, __TEXTURE__ p_TexB)
{
float3 x = make_float3(_tex2D(p_TexR, p_X, p_Y),
_tex2D(p_TexG, p_X, p_Y),
_tex2D(p_TexB, p_X, p_Y));
// Do something here with a 3-pixel:
x.x += x.x + 0.1f;
return x;
}



A more fancy extension would be to have a prior and next frame pointer as well.

[Myrsloik]

Achooo

I'm allergic to proprietary crap

[Cary Knoop]

Achooo

I'm allergic to proprietary crap
Then use OpenCL.

I think having such an interface would be a great addition to Vapoursynth. And once you have the inferface spec one could write other adapters like for CUDA or other GPU languages.

[HuBandiT]

The current filter model of operating on whole frames is also very memory bandwidth inefficient. Adding support for filters that work per scanline/tile will allow for huge improvements since then L3 and L2 cache speed would be the limit and not ram.

Amen! One day perhaps the JIT in VS will be enhanced enough to allow users to write filter chains and then do Expression Templates (https://en.wikipedia.org/wiki/Expression_templates)-type optimization on them, fully exploiting available locality. :D

(Until then maybe vsFilterScript will get there first.)

[stax76]

VapourSynth is not mentioned in the Wikipedia Frameserver article (https://en.wikipedia.org/wiki/Frameserver). I don't have much time and Wikipedia experience.

[feisty2]

vsFilterScript is now ready for general purpose use, and ready to retire vsxx as the modern vs C++ api wrapper.
it has successfully achieved zero cost abstraction, the test filter runs even faster than the corresponding core filter bundled with vaporsynth (https://forum.doom9.org/showthread.php?p=1919843#post1919843).
and it comes with much prettier syntax and higher level of abstraction FOR FREE!

[Myrsloik]

R51 released! (https://github.com/vapoursynth/vapoursynth/releases/tag/R51)

Not that exciting. Get ready for the considerably more exciting audio and api development builds soon.

[mastrboy]

Get ready for the considerably more exciting audio and api development builds soon.

Nice, I might finally switch over from Avisynth after audio support has been released.

Will there be source filters for audio available when the core gets audio support?

[Myrsloik]

Nice, I might finally switch over from Avisynth after audio support has been released.

Will there be source filters for audio available when the core gets audio support?

BestAudioSource is already available. How else could I test things?

I encourage the the curious among you to take a look at the audio test builds (https://forum.doom9.org/showthread.php?t=177623).

[lansing]

I have problem setting the color of blankclip referenced from a YUV444P16 clip.


clip_yuv16 = core.resize.Bicubic(clip, format=vs.YUV444P16)
color_clip = core.std.BlankClip(clip_yuv16, color=[0, 0, 220])
color_clip.set_output()

This gives me a dark green frame

[Myrsloik]

I have problem setting the color of blankclip referenced from a YUV444P16 clip.


clip_yuv16 = core.resize.Bicubic(clip, format=vs.YUV444P16)
color_clip = core.std.BlankClip(clip_yuv16, color=[0, 0, 220])
color_clip.set_output()

This gives me a dark green frame

Sounds right with those values. Why do you think it should be something else?

[lansing]

Sounds right with those values. Why do you think it should be something else?

I think it should take RGB values and converted it to the destine format implicitly, because at the end of the day, we only need to produce a simple colored blankclip, people shouldn't need to look up the equation on their own in order to convert RGB value to YUV.

[_Al_]

yeah, it is yuv because of format, is value 220 as 8 bit? For 16 bit it would be:
clip_yuv16 = core.resize.Bicubic(clip, format=vs.YUV444P16)
MaxSize16bit = 2**16-1
color_clip = core.std.BlankClip(clip_yuv16, color=[0, 0, 220/255*MaxSize16bit])
color_clip.set_output()
setting colors in yuv could get weird if not gray, better set it in RGB and then convert it

[lansing]

yeah, it is yuv because of format, is value 220 as 8 bit? For 16 bit it would be:
clip_yuv16 = core.resize.Bicubic(clip, format=vs.YUV444P16)
MaxSize16bit = 2**16-1
color_clip = core.std.BlankClip(clip_yuv16, color=[0, 0, 220/255*MaxSize16bit])
color_clip.set_output()
setting colors in yuv could get weird if not gray, better set it in RGB and then convert it

Is the "color" argument ordered as R,G,B? Because RGB(0,0,220) should be blue but the function gave me red.

[_Al_]

If format is YUV or attribute clip has that format then it is [Y,U,V].
To start as RGB you'd need one more conversion line, to set your 8bit 220 blue for final YUV 16bit for exampler:
color_clip = core.std.BlankClip(format=vs.RGB24, color=[0,0,220])
color_clip = color_clip.resize.Point(format=vs.YUV444P16, matrix_s='709')
color_clip.set_output()

[Myrsloik]

I think it should take RGB values and converted it to the destine format implicitly, because at the end of the day, we only need to produce a simple colored blankclip, people shouldn't need to look up the equation on their own in order to convert RGB value to YUV.

I give full control to the user. It makes no sense to not allow the user to set certain YUV values that can't be represented as RGB. If you say "automatic conversion" I simply say: which matrix and transfer function?

[feisty2]

ShufflePlanes should automatically strip the "_Matrix" property if the target color family is vs.GRAY. otherwise an error message pops up bitchin' about "no _Matrix stuff allowed for GRAY" or whatever and you have to manually remove the "_Matrix" thingy before ShufflePlanes which is very annoying.

[feisty2]

you can reproduce the error using the following script


clp = core.std.BlankClip(format=vs.YUV444PS)
clp = core.fmtc.matrix(clp, "601")
clp = core.std.ShufflePlanes(clp, 0, vs.GRAY) # Resize error 1026: GRAY color family cannot have RGB matrix coefficients

[ChaosKing]

Can reproduce with R51 and also with R51-audio-test5.

Did you copy the text? Because my GRAY is spelled GREY here:
Resize error 1026: GREY color family cannot have RGB matrix coefficients

[feisty2]

nah, I was replying on my phone so I typed the error message shown on my computer, I didn't pay that much attention to the spelling of each word while I was typing

[Myrsloik]

ShufflePlanes should automatically strip the "_Matrix" property if the target color family is vs.GRAY. otherwise an error message pops up bitchin' about "no _Matrix stuff allowed for GRAY" or whatever and you have to manually remove the "_Matrix" thingy before ShufflePlanes which is very annoying.

There's no right answer here. Often it's reassembled again and then you want the matrix to be carried over.