Vapoursynth

[Selur]

The core resizer is pipelined, so combining multiple operations into one call avoids extra VS caches and memory copies.
Sounds like in an average script with multiple filters it probably doesn't really matter. :)

In fact, restoration filters like deblock/dering should probably operate on the original image.
Don't think that color matrix changes should have an impact on deblocking/deringing filters, since it shouldn't change the macroblocks positioning like cropping would.

[Selur]

Small question when I have to clips (left, right) I want to StackHorizontal, how can I do something like this in Vapoursynth?
if(left.color_space != right.color_space){
left = convertToColorspace(left, right.color_space);
}

Thanks!

[Mystery Keeper]

Small question when I have to clips (left, right) I want to StackHorizontal, how can I do something like this in Vapoursynth?
if(left.color_space != right.color_space){
left = convertToColorspace(left, right.color_space);
}

Thanks!left = core.resize.Spline36(left, format=right.format.id)
diff = core.std.StackHorizontal([left, right])

[Selur]

Thanks :)

[Myrsloik]

R37 RC1 (https://dl.dropboxusercontent.com/u/73468194/VapourSynth-R37-RC1.exe)

I just want to fix one final bug in avfs that causes random crashes for avisynth peasants before the final release. It's very safe to use since this time it's all bug fixes.

Changes:
fixed blankclip and addborders sometimes rejecting valid floating point color values (jackoneill)
vdecimate no longer stores the metrics for all frames, thus saving a lot of memory for long clips (jackoneill)
changed get_read* functions in python so their memory no longer incorrectly is writable (Kamekameha)
added rational number fps property to clips in python (Kamekameha)
mostly worked around an issue where python would replace the sigint handler
fixed bug that could sometimes cause false memory leak warnings when freeing core
fixed possible corruption on frames without subtitles in subtext (jackoneill)
added a proxy object to avoid referencing the wrong core in scripts (stuxcrystal)

[hydra3333]

Just a thought.

Has anyone noted the nvidia-GPU accelerated filters for deinterlace / knlmeans / lsf over at DG's site ?

Reported phenomenal speeds as compared to equivalent cpu based filters.

http://rationalqm.us/board/viewtopic.php?f=8&t=506
http://rationalqm.us/board/viewtopic.php?f=8&t=558

[hydra3333]

Per this post http://rationalqm.us/board/viewtopic.php?f=8&t=506&p=6250#p6248 about the 2 new filters DGDenoise DGSharpen which use the GPU for seriously sped up filtering, I get now these messages all the time:
Avisynth Compat: requested frame xxx not prefetched, using slow method
and then this
Core freed but 645120 bytes still allocated in framebuffers

A quick peek at this code https://github.com/vapoursynth/vapoursynth/blob/master/src/avisynth/avisynth_compat.cpp seems to suggest to an uninitiated person that it could be updated to take into account DGDenoise and DGSharpen ? If so could that please be done ? Or, advice on what else should be done.

I and presumably some others would like to benefit from gpu accelerated filters yielding eye-wateringly fast speeds :)

Thanks.

[Myrsloik]

Per this post http://rationalqm.us/board/viewtopic.php?f=8&t=506&p=6250#p6248 about the 2 new filters DGDenoise DGSharpen which use the GPU for seriously sped up filtering, I get now these messages all the time:

and then this


A quick peek at this code https://github.com/vapoursynth/vapoursynth/blob/master/src/avisynth/avisynth_compat.cpp seems to suggest to an uninitiated person that it could be updated to take into account DGDenoise and DGSharpen ? If so could that please be done ? Or, advice on what else should be done.

I and presumably some others would like to benefit from gpu accelerated filters yielding eye-wateringly fast speeds :)

Thanks.
I need the filter names and which frames they need as input to produce one frame of output. It's that simple.

[hydra3333]

I need the filter names and which frames they need as input to produce one frame of output. It's that simple.

All good. Their names are DGDenoise and DGSharpen and they both use only the current frame. I suppose DGSource doesn't need mentioning.

Thanks !

[Cary Knoop]

All good. Their names are DGDenoise and DGSharpen and they both use only the current frame.
I personally would not bother with a GPU denoiser only using the current frame.

[TheFluff]

Per this post http://rationalqm.us/board/viewtopic.php?f=8&t=506&p=6250#p6248 about the 2 new filters DGDenoise DGSharpen which use the GPU for seriously sped up filtering, I get now these messages all the time:

and then this


A quick peek at this code https://github.com/vapoursynth/vapoursynth/blob/master/src/avisynth/avisynth_compat.cpp seems to suggest to an uninitiated person that it could be updated to take into account DGDenoise and DGSharpen ? If so could that please be done ? Or, advice on what else should be done.

I and presumably some others would like to benefit from gpu accelerated filters yielding eye-wateringly fast speeds :)

Thanks.

For the record, the "slow" method that you're getting warned about simply replicates what (single threaded) Avisynth does. Execution is completely serial and synchronous. Say that you request frame 3 from a temporal filter that requires one frame before the requested frame and one frame after the requested frame to produce output. With the slow (Avisynth) method, you call GetFrame(3), then the filter requests frame 2 from the upstream filter, waits for it to return, requests frame 3, waits for that to return, requests frame 4, waits for that to return, does its processing, and then returns a frame. The filter can tell Avisynth which frames would be useful to cache, but that's the extent of it. It's awful, but that's software from 2001 for you.

When VS loads Avisynth filters via the fake Avisynth environment, the filters that have been whitelisted (together with what frames they are expected to require to produce an output frame) are actually parallelized to a certain degree. Only one thread will call the filter's (Avisynth) GetFrame function at a time, so the actual processing is still single-threaded, but since VS knows in advance what frames the filter is going to request from the upstream filter if you request frame n, those frames are pre-fetched (in parallel, if the upstream filter supports it) before the filter's GetFrame(n) is ever called and any GetFrame requests from within the filter can return immediately. Even spatial only filters benefit (they still require one frame from the upstream filter, and that frame can be prefetched). Whitelisted filters also play nicer with parallelized downstream filters, since they can request many frames in parallel from the Avisynth filter wrapper, which then requests many frames in parallel from the upstream filters.

In other words: in single threaded, original Avisynth, only one filter can do work at a time. Every other filter spends all its time waiting for processing getting done somewhere else. When a single threaded Avisynth filter is used in VS, in an ideal world it can sit in its own thread and do processing as fast it can, never waiting on input (because the input is being processed in many other threads in parallel), while filters that do further processing on its output aren't bottlenecked on waiting for the Avisynth filter's input, and potentially not even on the Avisynth filter itself.

[Selur]

Small question: Is there something like Restore24 for Vapoursynth?

[ChaosKing]

yes, there is srestore: https://forum.doom9.org/showthread.php?t=166582

[feisty2]

@Myrsloik
is the global core allowed again from r37 and on?
is it ok to code the module like

import vapoursynth as vs
xxx = vs.core.yyy.xxx
def f(src):
return xxx(src)

?

[Myrsloik]

@Myrsloik
is the global core allowed again from r37 and on?
is it ok to code the module like

import vapoursynth as vs
xxx = vs.core.yyy.xxx
def f(src):
return xxx(src)

?

Sure is, that's completely equivalent from python's perspective. Why you want to prefix everything with 'vs.' is a mystery though...

[feisty2]

Sure is, that's completely equivalent from python's perspective. Why you want to prefix everything with 'vs.' is a mystery though...

I don't want to prefix everything with "vs", but I simply can't go with the from vapoursynth import core way cuz I need other stuff like "vs.VideoNode" or "vs.GRAY" and things like that..

[Are_]

Yeah, I also found the same problem, I could not pass stuff like "vs.YUV444P16" or whatever to these functions, I think it's not convenient at all. Also its bad practice in python to do imports inside functions.

[feisty2]

Also its bad practice in python to do imports inside functions.

you should import the core with a global import statement, not within functions

[Are_]

Mmmh... OK, I saw it somewhere used like that and I was thinking this was the new way of doing it.

[feisty2]

@Myrsloik
I think the global core is not working as expected in modules
so a test script like

from vapoursynth import core

BlankClip = core.std.BlankClip

def GenBlank(src):
return BlankClip(src)

ref = BlankClip()
clp = GenBlank(ref)
clp.set_output()

works without any problem, but if I separate it into a test module and a script like

#blah.py
from vapoursynth import core

BlankClip = core.std.BlankClip

def GenBlank(src):
return BlankClip(src)



#test script
from vapoursynth import core
import blah

BlankClip = core.std.BlankClip

ref = BlankClip()
clp = blah.GenBlank(ref)
clp.set_output()


I get the following error:

Failed to evaluate the script:
Python exception: BlankClip: nodes foreign to this core passed as input, improper api usage detected

Traceback (most recent call last):
File "src\cython\vapoursynth.pyx", line 1821, in vapoursynth.vpy_evaluateScript (src\cython\vapoursynth.c:36464)
File "", line 7, in <module>
File "C:\Program Files\Python36\lib\site-packages\blah.py", line 6, in GenBlank
return BlankClip(src)
File "src\cython\vapoursynth.pyx", line 1713, in vapoursynth.Function.__call__ (src\cython\vapoursynth.c:34604)
vapoursynth.Error: BlankClip: nodes foreign to this core passed as input, improper api usage detected

[Myrsloik]

@Myrsloik
I think the global core is not working as expected in modules
so a test script like

from vapoursynth import core

BlankClip = core.std.BlankClip

def GenBlank(src):
return BlankClip(src)

ref = BlankClip()
clp = GenBlank(ref)
clp.set_output()

works without any problem, but if I separate it into a test module and a script like

#blah.py
from vapoursynth import core

BlankClip = core.std.BlankClip

def GenBlank(src):
return BlankClip(src)



#test script
from vapoursynth import core
import blah

BlankClip = core.std.BlankClip

ref = BlankClip()
clp = blah.GenBlank(ref)
clp.set_output()


I get the following error:

The improvement was only about core references, now you're storing function references (which are also per core). That's a bad habit. Don't be clever.

[feisty2]

The improvement was only about core references, now you're storing function references (which are also per core). That's a bad habit. Don't be clever.

I just wanna simplify (remove the extra namespaces) the function calling process... like, I personally prefer "BlankClip" over "core.std.BlankClip"

I think this

from vapoursynth import core

class c:
def __init__(self):
self.BlankClip = core.std.BlankClip

def GenBlank(src):
obj = c()
clip = obj.BlankClip(src)
del obj
return clip

is gonna work, at least now I can shrink 2 namespaces down to 1.

[Myrsloik]

Here's R37 RC2 (https://dl.dropboxusercontent.com/u/73468194/VapourSynth-R37-RC2.exe). It fixes avfs crashes with avisynth and not much else. It's also compiled with a combination of vs2017 and clang to make things interesting. Will be released if nobody dies from testing it.

[sneaker_ger]

R37 RC2: error about missing libgcc_s_seh-1.dll

[Myrsloik]

R37 RC2: error about missing libgcc_s_seh-1.dll

When you do what exactly? only a few of the included plugins are compiled with gcc and never need extra dlls. Could it be caused by an autoloaded plugin?

[sneaker_ger]

Yes, it seems to be caused by core64\plugins\libsubtext.dll. Once I delete that the error message is gone.

import vapoursynth as vs
core = vs.get_core()
ret = core.std.BlankClip()
ret.set_output()
vspipe --info script.vpy -
It works normally despite the error message, though.

No error message with libsubtext.dll from R36 copied into R37 RC2.

[Mystery Keeper]

I get that error too.

[Myrsloik]

Yes, it seems to be caused by core64\plugins\libsubtext.dll. Once I delete that the error message is gone.

import vapoursynth as vs
core = vs.get_core()
ret = core.std.BlankClip()
ret.set_output()
vspipe --info script.vpy -
It works normally despite the error message, though.

No error message with libsubtext.dll from R36 copied into R37 RC2.

Sigh, I'll have to spank jackoneill for miscompiling the fixed version. And I found one more place where the useless avisynth 2.6 api could cause crashes in avfs. Expect RC3 soon...

[Myrsloik]

R37 RC3 (https://dl.dropboxusercontent.com/u/73468194/VapourSynth-R37-RC3.exe)

Fixes the missing dll stuff with libsubtext, I'd appreciate if someone can verify that it works properly too. Also fixes one more avfs issue. Probably the last RC.

[sneaker_ger]

Can confirm: no error with R37 RC3.

[Mystery Keeper]

Same. No error with R37 RC3.

[Myrsloik]

R37 is released. The Avisynth API sucks. Sky still blue.

[Myrsloik]

The R37 binaries have now been updated. The released ones were unfortunately miscompiled which caused a pile of issues.

[stax76]

Is it correct that VC++ 2017 uses the same filename (msvcp140.dll) as VC++ 2015 runtime?

[Myrsloik]

Yes, the vs2017 runtime replaces the vs2015 one

[Myrsloik]

I just fixed an issue with the portable version. Previously it included vs2017 runtime dlls that only work on win8 and newer. Now it's fixed and win7 is once again properly supported. You only have to re-download if it failed to launch before.

All the fun of switching compilers... The current release requires VS2015, VS2017 AND clang to compile. Hopefully Python will add support for VS2017 too so it's reduced to only two compilers for the next release.

[hydra3333]

All good. Their names are DGDenoise and DGSharpen and they both use only the current frame. I suppose DGSource doesn't need mentioning.
Thank you for adding them to R37.

https://github.com/vapoursynth/vapoursynth/blob/master/src/avisynth/avisynth_compat.cpp
myrsloik Impertinently add DGSharpen and DGWhatever to prefetch list :)

[hydra3333]

Per this post http://rationalqm.us/board/viewtopic.php?f=4&t=463&sid=c75bd90411392cb95d229e81c3b59573&p=6380#p6380 DG has added 2 new avisynth gpu accelerated filters,
Added fast CUDA filters DGTelecide and DGDecimate
and will be adding more new gpu accelerated filters in the near future, eg DGDeblock http://rationalqm.us/board/viewforum.php?f=14

Everyone loves to have quality good and extremely fast filters ... So now wondering 2 things :-

1. can we please add these to Vapoursynth i.e. https://github.com/vapoursynth/vapoursynth/blob/master/src/avisynth/avisynth_compat.cpp ?

2. How can we add new filters quickly from time to time without having to wait for new releases of Vapoursynth ?
It was suggested that maybe have a user-editable config file so that we can add our own filter definitions from time to time pending new releases of Vapoursynth ?
Such an approach would be really handy for other new and updated filters too.

[Selur]

How can we add new filters quickly from time to time without having to wait for new releases of Vapoursynth ?
Manual loading, like when you load from a location that isn't the default plugins folder, should work. Shouldn't it?

[hydra3333]

Manual loading, like when you load from a location that isn't the default plugins folder, should work. Shouldn't it?

Yes manual loading should work fine. Modifying that file isn't about loading it, it's apparently about Vapoursynth knowing how many frames a filter will fetch in both directions for parallelism reasons :) or something like that.

[Myrsloik]

Per this post http://rationalqm.us/board/viewtopic.php?f=4&t=463&sid=c75bd90411392cb95d229e81c3b59573&p=6380#p6380 DG has added 2 new avisynth gpu accelerated filters,

and will be adding more new gpu accelerated filters in the near future, eg DGDeblock http://rationalqm.us/board/viewforum.php?f=14

Everyone loves to have quality good and extremely fast filters ... So now wondering 2 things :-

1. can we please add these to Vapoursynth i.e. https://github.com/vapoursynth/vapoursynth/blob/master/src/avisynth/avisynth_compat.cpp ?

2. How can we add new filters quickly from time to time without having to wait for new releases of Vapoursynth ?
It was suggested that maybe have a user-editable config file so that we can add our own filter definitions from time to time pending new releases of Vapoursynth ?
Such an approach would be really handy for other new and updated filters too.

1. Sure, I'll add them.

2. You don't, write native stuff. Or recompile only avscompat.dll on your own. All you need is vs2017 community which is free.

[hydra3333]

1. Sure, I'll add them.

2. You don't, write native stuff. Or recompile only avscompat.dll on your own. All you need is vs2017 community which is free.

Beaut, thanks.

OK "vs2017 community" to recompile only a "portable" avscompat.dll on my own ... now I'm off to look up how to do that for x64 :) and then plonk a replacement AvsCompat.dll under
Vapoursynth\vapoursynth64\coreplugins

Very definitely looking forward to an expanded set of amazingly fast GPU accelerated filters :)
Imagine, if you would, a gpu based QTGMC or equivalent (well, one can always live in hope).
Exciting times !

[Pat357]

After I got the info about fmtconv being no longer updated, I started looking at ZIMG (again!)
Do we still need the ZIMG (libzimg) plugin with the current VS37 or is this completely included in VS ?

I know the build-in resizers are based on the Zimg lib., but maybe for some other things we still need the whole lib.
What is the name-space to access the Zimg lib functions directly ?
Anyway, without my (outdated) plugin loaded, I don't see the Z name-space in the function list.

Also the same question about libimwri.dll. Is this plugin still needed ?

[TheFluff]

zimg is bundled with VS. core.resize.whatever just calls zimg directly - there are no VS-specific resizers that are based on zimg. There is no more functionality in zimg than what's in core.resize, as far as I know.

[Pat357]

Thanks, so the Zimg lib plugin is no longer required or even supported.

What about the ImageMagick Writer-Reader ? In the VS documentation it says "in the source tree".
I guess this is also compiled in VS and we don't need a separate plugin for it ? correct ?

[Myrsloik]

Thanks, so the Zimg lib plugin is no longer required or even supported.

What about the ImageMagick Writer-Reader ? In the VS documentation it says "in the source tree".
I guess this is also compiled in VS and we don't need a separate plugin for it ? correct ?

You still need a separate plugin on windows due to it being huge. And not working as well as I'd like.

[Pat357]

Any URL to download the current version from libimwri.dll (ImageMagick Writer-Reader for Windows) ?
I found my version somewhere it the tread about it dd 08/06/2016.

It would be a good idea to add an url for libimwri.dll to your "documentation" from VS homepage, just as you did for all other plugins.

[Izuchi]

I'd like some assistance regarding how to do fade in/outs. I tried following jackoneill's example (posted 3 years ago) but no luck.



fade_input = # your source here
blank = core.std.BlankClip(clip=fade_input, length=1, color=[255, 128, 128]) # assumes you're working with 8 bit YUV
fade_frames = []
for i in range(fade_input.num_frames):
fade_frames.append(core.std.Merge(clips=[fade_input[i], blank], weight=i/(fade_input.num_frames-1)))
fade_output = core.std.Splice(clips=fade_frames)



While I'm at it, is it possible to implement fade in/out as an in-built function rather than a script?

[Myrsloik]

I'd like some assistance regarding how to do fade in/outs. I tried following jackoneill's example (posted 3 years ago) but no luck.



While I'm at it, is it possible to implement fade in/out as an in-built function rather than a script?

"no luck" means what exactly?

[Izuchi]

"no luck" means what exactly?

Nevermind, I just found out that the reason why it wasn't working was because the arguments for Merge had changed since jackoneill's initial post three years ago. Everything's now working as it should.