View Full Version : Vapoursynth
lansing
5th December 2017, 05:57
Ok that looks better than my dummy clip. Didn't know that you can pack those shortcut format into the splice function.
tyee
6th December 2017, 04:58
Just starting to learn VS, but can't find links to any 64 bit plugins to test a script. Trying to find RemoveGrain.dll and Repair.dll to test finesharp script. Anyone got links?
update - ok, I read they are not needed anymore but I would like to know where the 64 bit plugins reside?
lansing
6th December 2017, 06:26
Just starting to learn VS, but can't find links to any 64 bit plugins to test a script. Trying to find RemoveGrain.dll and Repair.dll to test finesharp script. Anyone got links?
update - ok, I read they are not needed anymore but I would like to know where the 64 bit plugins reside?
http://www.vapoursynth.com/doc/pluginlist.html
lansing
6th December 2017, 07:10
Updating on my issue with loading multiple instances of a virtualdub filters. I did more testings on a few more vd filters, the problem should be coming from either avisynth or virtualdub. (I highly believe that it's avisynth)
Loading multiple instance of any vd filter in an avs script will result in an "out-of-bound memory access" crash on program close, which is the same behavior I had in vapoursynth earlier.
This will crash in avisynth:
LoadVirtualDubPlugin("Autolevels.vdf", "Autolevels", 0)
src = AVISource("sample.avi").ConvertToRGB32()
a = src.Autolevels(40, 46, 50, 0, 0, 0, 0, 0)
b = src.Autolevels(40, 80, 50, 0, 0, 0, 0, 0)
a+b
This will work:
LoadVirtualDubPlugin("Autolevels.vdf", "Autolevels", 0)
LoadVirtualDubPlugin("Autolevels_copy.vdf", "Autolevels_copy", 0)
src = AVISource("sample.avi").ConvertToRGB32()
a = src.Autolevels(40, 46, 50, 0, 0, 0, 0, 0)
b = src.Autolevels_copy(40, 80, 50, 0, 0, 0, 0, 0)
a+b
pinterf
6th December 2017, 08:54
Updating on my issue with loading multiple instances of a virtualdub filters. I did more testings on a few more vd filters, the problem should be coming from either avisynth or virtualdub. (I highly believe that it's avisynth)
Loading multiple instance of any vd filter in an avs script will result in an "out-of-bound memory access" crash on program close, which is the same behavior I had in vapoursynth earlier.
Yes, already reported, something like a double free at exit, don't spend any more time investigating on the vs side.
lansing
6th December 2017, 19:01
Yes, already reported, something like a double free at exit, don't spend any more time investigating on the vs side.
Ok hope this get fix soon, getting it to work fills in the last missing piece of my project.
lansing
9th December 2017, 04:46
Is there a function that can replace a range of frames with another range of frame of the same clip?
I want to replace frame 200-250 with frame 0-150. It's not remapping, the length of the resulting clip should be different to the original. I looked into remapframes but it doesn't have it.
AzraelNewtype
9th December 2017, 07:28
Sure.
http://www.vapoursynth.com/doc/functions/trim.html
http://www.vapoursynth.com/doc/functions/splice.html
lansing
9th December 2017, 08:20
Sure.
http://www.vapoursynth.com/doc/functions/trim.html
http://www.vapoursynth.com/doc/functions/splice.html
I know that we can write it using those native functions. I'm just asking to see if we have something written already.
I have another question about slicing, is there a short form to get a clip of N frame to the end of the clip? "clip[50, -1]" only gets frame 50 to the second to the last frame, is there a flag that represent the last frame of the clip?
AzraelNewtype
9th December 2017, 09:51
clip[50:]
Of course [:-1] is only giving the second to last. That's what negative slice indexes do.
As for wrapping three trims and a splice to do arbitrary replacement of unrelated clips, that kind of really small helper function isn't the sort of thing people share libraries of. A naive implementation is probably about five lines. It's barely even syntactic sugar if you have to define the trim points of the input and replacement separately.
lansing
11th December 2017, 17:22
Reporting a memory leak on ModifyFrame as I found it here (https://forum.doom9.org/showthread.php?p=1826659#post1826659) earlier.
Memory will not flush after I closed preview in vs editor. Using the sample script from the document will cause the leak:
def set_frame_number(n, f):
fout = f.copy()
fout.props['FrameNumber'] = n
return fout
clip = core.std.ModifyFrame(clip=clip, clips=clip, selector=set_frame_number)
Myrsloik
12th December 2017, 13:22
Reporting a memory leak on ModifyFrame as I found it here (https://forum.doom9.org/showthread.php?p=1826659#post1826659) earlier.
Memory will not flush after I closed preview in vs editor. Using the sample script from the document will cause the leak:
def set_frame_number(n, f):
fout = f.copy()
fout.props['FrameNumber'] = n
return fout
clip = core.std.ModifyFrame(clip=clip, clips=clip, selector=set_frame_number)
I've found 3 memory leaks so far in various places. Expect the next version to improve on things a lot. Note that all leaks more or less only happened when objects were destroyed so it'd never be discovered when using vspipe or simply encoding things.
Myrsloik
12th December 2017, 16:43
R41-test1 (https://www.dropbox.com/s/q2gb0hmuh3ywyiy/VapourSynth-R41-test1.exe?dl=1)
Some of the fixes required fairly big changes in the cython code so test as many scripts as possible. This binary should be considered alpha quality.
r41:
updated to zimg v2.7
removed dependency on the now deprecated codecvt header
fixed memory leak where modifyframe wouldn't release the function reference when done
fixed a rare memory leak that could happen if the core was freed before the last frame
fixed a memory leak that would happen if a python videoframe object was instantiated
improved imwri's input and output format guessing, now integer and float image formats will most likely be returned in native precision
imwri now requires hdri support since it's now enabled by default
stackvertical now properly rejects compat formats instead of producing unexpected output
the default initial cache size now also depends on the number of threads used
fixed negative frame request error listing the parent node name instead of the correct name
fixed expr clamping of 9-15 bit output, previously it would clamp to 16bit
fixed corrupted output in expr when mixing int and float for input and output (pinterf)
Imwri builds will be provided separately at a later time when more testing has been done.
lansing
12th December 2017, 22:21
Thank you, the leak is now gone, memory usage drops back to 30MB after preview close.
Can I output image file name with imwrif base on frame number in the frame property?
If you call imwri insode frameeval ypu should be able to do it.
I can't get it working, I tried various formatings but all failed.
from functools import partial
img_dir = r"F:\temp_img_w\{}.png"
def set_frame_number(n, f):
fout = f.copy()
fout.props.FrameNumber = n
return fout
clip = core.std.ModifyFrame(clip=clip, clips=clip, selector=set_frame_number)
def writeimgfn(n, f, clip, path):
num = f.props.FrameNumber
rgb_clip = core.resize.Bicubic(clip, matrix_in_s="709", format=vs.RGB24)
return core.imwrif.Write(rgb_clip, imgformat="PNG", filename=path.format(n))
clip = core.std.FrameEval(clip, partial(writeimgfn, clip=clip, path=img_dir), prop_src=clip)
clip.set_output()
It returns error "Write: Filename string doesn't contain a number".
Myrsloik
12th December 2017, 22:40
Thank you, the leak is now gone, memory usage drops back to 30MB after preview close.
I can't get it working, I tried various formatings but all failed.
from functools import partial
img_dir = r"F:\temp_img_w\{}.png"
def set_frame_number(n, f):
fout = f.copy()
fout.props.FrameNumber = n
return fout
clip = core.std.ModifyFrame(clip=clip, clips=clip, selector=set_frame_number)
def writeimgfn(n, f, clip, path):
num = f.props.FrameNumber
rgb_clip = core.resize.Bicubic(clip, matrix_in_s="709", format=vs.RGB24)
return core.imwrif.Write(rgb_clip, imgformat="PNG", filename=path.format(n))
clip = core.std.FrameEval(clip, partial(writeimgfn, clip=clip, path=img_dir), prop_src=clip)
clip.set_output()
It returns error "Write: Filename string doesn't contain a number".
Unless you have a more complex use case than this example you should simply be using vspipe and ffmpeg to write images. How does your script fail anyway?
lansing
12th December 2017, 23:13
Unless you have a more complex use case than this example you should simply be using vspipe and ffmpeg to write images. How does your script fail anyway?
I'm working on a project to color match dragon ball z, for better color matching accuracy, I need to build a big montage for every scene and stored them as a clip, like 1 frame = 1 montage, each frame resolution varies. After that I need to output all the images to be use for the color matching program.
By tagging and saving a frame number onto each output image instead of the sequence counter will help to back track if something went wrong. For example, if one of the images gives poor matching result, I would know exactly where to look for that scene.
gonca
14th December 2017, 00:44
Using Vapoursynth to try to process a UHD video
script is
import vapoursynth as vs
core = vs.get_core()
core.avs.LoadPlugin(r'C:\Program Files (Portable)\dgdecnv\x64 Binaries\DGDecodeNV.dll')
clip = core.avs.DGSource(r'D:\#TEMP\xxxx.dgi', fieldop=0, fulldepth=True)
clip.set_output()
error report
Error Video encoding using NVEnc 3.23 (1.7.0.4)
Video encoding using NVEnc 3.23 failed with exit code: -1073741819 (0xC0000005)
The exit code might be a system error code: The instruction at 0xp referenced memory at 0xp. The memory could not be s.
------------------- Video encoding using NVEnc 3.23 -------------------
"C:\Program Files (Portable)\StaxRip\Apps\NVEnc\NVEncC64.exe" --vbrhq 38400 --codec h265 --preset quality --level 5.1 --output-depth 10 --weightp --ref 5 --gop-len 24 --lookahead 32 --qp-init 1 --max-bitrate 38400 --vbr-quality 25 --aq --cuda-schedule auto --colormatrix bt2020nc --colorprim bt2020 --transfer smpte2084 --mv-precision q-pel --cabac -i "W:\TEMP\KONG SKULL ISLAND_temp\KONG SKULL ISLAND.vpy" -o "W:\TEMP\KONG SKULL ISLAND_temp\KONG SKULL ISLAND_out.h265"
StaxRip.ErrorAbortException: Video encoding using NVEnc 3.23 failed with exit code: -1073741819 (0xC0000005)
The exit code might be a system error code: The instruction at 0xp referenced memory at 0xp. The memory could not be s.
------------------- Video encoding using NVEnc 3.23 -------------------
"C:\Program Files (Portable)\StaxRip\Apps\NVEnc\NVEncC64.exe" --vbrhq 38400 --codec h265 --preset quality --level 5.1 --output-depth 10 --weightp --ref 5 --gop-len 24 --lookahead 32 --qp-init 1 --max-bitrate 38400 --vbr-quality 25 --aq --cuda-schedule auto --colormatrix bt2020nc --colorprim bt2020 --transfer smpte2084 --mv-precision q-pel --cabac -i "W:\TEMP\KONG SKULL ISLAND_temp\KONG SKULL ISLAND.vpy" -o "W:\TEMP\KONG SKULL ISLAND_temp\KONG SKULL ISLAND_out.h265"
at StaxRip.Proc.Start() in D:\Projekte\VS\VB\StaxRip\General\Proc.vb:line 338
at StaxRip.NVEnc.Encode() in D:\Projekte\VS\VB\StaxRip\Encoding\NVEnc.vb:line 82
at StaxRip.GlobalClass.ProcessVideo() in D:\Projekte\VS\VB\StaxRip\General\GlobalClass.vb:line 225
at System.Threading.Tasks.Parallel.<>c__DisplayClass4_0.<Invoke>b__0()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at StaxRip.GlobalClass.ProcessJob(String jobPath) in D:\Projekte\VS\VB\StaxRip\General\GlobalClass.vb:line 137
If I run
"C:\Program Files (Portable)\StaxRip\Apps\NVEnc\NVEncC64.exe" --vbrhq 38400 --codec h265 --preset quality --level 5.1 --output-depth 10 --weightp --ref 5 --gop-len 24 --lookahead 32 --qp-init 1 --max-bitrate 38400 --vbr-quality 25 --aq --cuda-schedule auto --colormatrix bt2020nc --colorprim bt2020 --transfer smpte2084 --mv-precision q-pel --cabac -i "W:\TEMP\KONG SKULL ISLAND_temp\KONG SKULL ISLAND.vpy" -o "W:\TEMP\KONG SKULL ISLAND_temp\KONG SKULL ISLAND_out.h265"
Through the command line The error is Vapoursynth failed to open input file
Any ideas?
kriNon
14th December 2017, 14:28
I'm trying to use vapoursynth's avs.LoadPlugin(string path) to load some avisynth filters, however whenever I try to load almost any filter I will get the error:
Failed to evaluate the script:
Python exception: Avisynth Loader: failed to load module
Traceback (most recent call last):
File "src\cython\vapoursynth.pyx", line 1830, in vapoursynth.vpy_evaluateScript (src\cython\vapoursynth.c:36860)
File "", line 4, in
File "src\cython\vapoursynth.pyx", line 1722, in vapoursynth.Function.__call__ (src\cython\vapoursynth.c:35000)
vapoursynth.Error: Avisynth Loader: failed to load module
Any idea what could be causing this? I'm running Vapoursynth r40 and Avisynth 2.6 x86.
Thanks!
Myrsloik
14th December 2017, 14:31
I'm trying to use vapoursynth's avs.LoadPlugin(string path) to load some avisynth filters, however whenever I try to load almost any filter I will get the error:
Failed to evaluate the script:
Python exception: Avisynth Loader: failed to load module
Traceback (most recent call last):
File "src\cython\vapoursynth.pyx", line 1830, in vapoursynth.vpy_evaluateScript (src\cython\vapoursynth.c:36860)
File "", line 4, in
File "src\cython\vapoursynth.pyx", line 1722, in vapoursynth.Function.__call__ (src\cython\vapoursynth.c:35000)
vapoursynth.Error: Avisynth Loader: failed to load module
Any idea what could be causing this? I'm running Vapoursynth r40 and Avisynth 2.6 x86.
Thanks!
Did you escape the path properly?
kriNon
14th December 2017, 14:35
Ah sorry, forgot to post my script:
import vapoursynth as vs
core = vs.get_core()
core.avs.LoadPlugin(r"C:\Program Files (x86)\AviSynth\plugins\deen.dll")
Yeah, I did
LigH
14th December 2017, 14:36
I believe VapourSynth may not be able to load AviSynth plugins with the ancient v2.0 or v2.5 interfaces, but require v2.6... so: Do you have a few examples which plugins load and which don't?
kriNon
14th December 2017, 14:51
I've only tested a few, I remember that TIVTC v1.0.5 didn't work, but v1.0.9 worked. Neither Deen or eDeen have worked for me, however I've seen that in https://github.com/vapoursynth/vapoursynth/blob/master/src/avisynth/avisynth_compat.cpp there are the lines:
PREFETCHR1(deen)
PREFETCHR0(eDeen)
so I assume that there is compatibility?
Also someone used Deen in their vapoursynth script here:
https://gist.github.com/4re/bba3f65469acfe0ec08a
EDIT:
I tested a few avisynth plugins at random to see which ones worked, and can confirm that I got the same error message when trying to load Average, BlendWeight, ColorBalance, FFT3DFilter, and Vinverse.
I have recently reinstalled both Avisynth and Vapoursynth and am having the same error.
Are_
14th December 2017, 15:17
Sorry about that, I should delete it, it must not exist in current year.
Maybe you are trying to load 32bit plugins with 64bit vapoursynth or the other way around.
kriNon
14th December 2017, 15:20
Does 64bit vapoursynth not support 32bit plugins?
LigH
14th December 2017, 16:00
64-bit processes can only handle 64-bit DLL's in general. That's not a restriction of specific software, but of the CPU mode and its memory addressing and register handling.
If you wanted to use a 32-bit DLL, you would have to spawn a separate 32-bit process and exchange data between both of them.
kriNon
14th December 2017, 16:15
So I'm a little bit confused, would I need to uninstall vapoursynth and replace it with a 32-bit variant? or would I need to replace python with a 32 bit variant? or both?
LigH
14th December 2017, 16:23
VapourSynth is a Python module. To run VapourSynth as a 32-bit process, you would have to run it in 32-bit Python.
kriNon
14th December 2017, 16:28
Alright, Thanks for all of the help!
lansing
14th December 2017, 21:45
Just saw the new one liner call to import the core
from vapoursynth import core
Now how do we get things like vs.RGB24 without the "vs"? The document haven't update yet.
Myrsloik
14th December 2017, 22:19
Just saw the new one liner call to import the core
from vapoursynth import core
Now how do we get things like vs.RGB24 with the "vs"? The document haven't update yet.
Same as the old import vapoursynth as vs. You can also do things like from vapoursynth import core, RGB24, someotherformat, ...If you want to refer to them without the vs prefix. Python has loads of ways to import things.
lansing
14th December 2017, 23:08
Same as the old import vapoursynth as vs. You can also do things like from vapoursynth import core, RGB24, someotherformat, ...If you want to refer to them without the vs prefix. Python has loads of ways to import things.
I'm referring to these:
core.std.BlankClip(format=vs.YUV420P8, length=1000, color=[n, 128, 128])
AzraelNewtype
14th December 2017, 23:16
Did... you... try
from vapoursynth import YUV420P8
?
lansing
14th December 2017, 23:40
Did... you... try
from vapoursynth import YUV420P8
?
That would be really odd if we need to import every little thing we're going to use in the first line. For example, I'm going to use COMPATBGR32, RGB24, YUV420P8 and RGBS in a script, so that would be:
from vapoursynth import COMPATBGR32, RGB24, YUV420P8, RGBS
AzraelNewtype
15th December 2017, 00:33
Yes that is correct. This is how python namespace pollution works. Alternately, don't pollute your namespace.
poisondeathray
17th December 2017, 04:00
avisource, alpha channel questions
R40 x64
There seems to be problems with the alpha channel using AVISource on an RGB32(RGBA) AVI with a valid alpha channel (I tested uncompressed, lagarith, ut video codec) . The same AVI is ok in avisynth, and showalpha() shows the correct alpha
import vapoursynth as vs
core = vs.get_core()
video = core.avisource.AVISource(r'F:\blah.avi', pixel_type="RGB32", alpha=True)
#video[0].set_output()
video[1].set_output()
It's not completely black, there are some pixels here and there that are non black, but it's definitely corrupt.
alpha channel seems to work ok with other things, e.g. on an imagemagick RGBA png sequence , video[1].set_output() would show the correct alpha
Q2) How do you send RGB32 data to something else ? . If python holds it as an array, how would you encode, say an RGBA png sequence with ffmpeg ?
Myrsloik
17th December 2017, 13:28
avisource, alpha channel questions
R40 x64
There seems to be problems with the alpha channel using AVISource on an RGB32(RGBA) AVI with a valid alpha channel (I tested uncompressed, lagarith, ut video codec) . The same AVI is ok in avisynth, and showalpha() shows the correct alpha
import vapoursynth as vs
core = vs.get_core()
video = core.avisource.AVISource(r'F:\blah.avi', pixel_type="RGB32", alpha=True)
#video[0].set_output()
video[1].set_output()
It's not completely black, there are some pixels here and there that are non black, but it's definitely corrupt.
alpha channel seems to work ok with other things, e.g. on an imagemagick RGBA png sequence , video[1].set_output() would show the correct alpha
Q2) How do you send RGB32 data to something else ? . If python holds it as an array, how would you encode, say an RGBA png sequence with ffmpeg ?
1. I think I found part of the issue. Can I have a sample with a few frames to test if I succeeded in fixing it? I think it broke during some refactoring and nobody noticed...
2. There's actually no easy way to do that. I mean ideally you'd output RGBAP but the default output handling doesn't take this into consideration. How about a solution like this:
clip.set_output(alpha=alpha_clip)
And then it'd be output as GBRAP. Or something like that, thoughts?
poisondeathray
17th December 2017, 18:15
UT Video ULRA , alpha channel sample
http://www.mediafire.com/file/lsb7cz35387ow1z/UTVideo_ULRA.avi
Let me know if you need any other samples / codecs etc...
clip.set_output(alpha=alpha_clip)
And then it'd be output as GBRAP. Or something like that, thoughts?
I think that should work, but would alpha=True be more consistent ? Or would you have to define the alpha_clip specifically ?
Myrsloik
17th December 2017, 19:26
UT Video ULRA , alpha channel sample
http://www.mediafire.com/file/lsb7cz35387ow1z/UTVideo_ULRA.avi
Let me know if you need any other samples / codecs etc...
I think that should work, but would alpha=True be more consistent ? Or would you have to define the alpha_clip specifically ?
How else would it know what the alpha information is?
Myrsloik
18th December 2017, 17:49
R41-test2 (https://www.dropbox.com/s/xw0l31pxqhdmrwo/VapourSynth-R41-test2.exe?dl=1)
Fixes alpha handling in avisource and not much else.
kgrabs
20th December 2017, 01:43
I think something is up with the "bits" and "floatout" parameters of std.Lut/Lut2, you can "evaluate" it but previewing and encoding crash:
import vapoursynth as vs
core = vs.core
clip = core.std.BlankClip(format=vs.GRAY8)
core.std.Lut(clip, lut=[0]*256, bits=16).set_output()
Script was successfully evaluated. Output video info:
Frames: 240 | Time: 0:00:10.000 | Size: 640x480 | FPS: 24/1 = 24 | Format: Gray16
Crash on preview
import vapoursynth as vs
core = vs.core
clip = core.std.BlankClip(format=vs.GRAY8)
core.std.Lut(clip, lutf=[0.]*256, bits=32, floatout=True).set_output()
Script was successfully evaluated. Output video info:
Frames: 240 | Time: 0:00:10.000 | Size: 640x480 | FPS: 24/1 = 24 | Format: GrayS
Crash on preview
~Edit~
So, std.BoxBlur seems to be really, really slow at copying planes. The difference between splitting to GRAY clips and using the planes parameter is huge
args = dict(hradius=2, hpasses=1, vradius=2, vpasses=1)
clip = core.std.BlankClip(None, 1920, 1080, vs.YUV444PS, 500)
core.std.BoxBlur(clip, planes=[0], **args).set_output()
Time elapsed: 0:07.476 - 66.88474253259326474108 FPS
clip = core.std.BlankClip(None, 1920, 1080, vs.GRAYS, 500)
core.std.BoxBlur(clip, **args).set_output()
Time elapsed: 0:02.996 - 166.90969959623313911834 FPS
Myrsloik
20th December 2017, 20:12
I'll look into the first one - FIXED NOW. Second is memory bw limited due to blankclip having to fill all 3 planes. Set keep=1 in blankclip and you'll see that it's really close. Or should be at least...
Myrsloik
27th December 2017, 15:20
R41-test4 (https://www.dropbox.com/s/ldplss7dpz8mwjc/VapourSynth-R41-test4.exe?dl=1)
It's a test version because some fairly big changes have been made for the alpha output part. To use this simply do clip.set_output(alpha=alpha_clip) and it will be output through vspipe. Note that Y4M doesn't get alpha and can't be combined with it. Test it well.
r41:
updated to zimg v2.7
added convenient alpha output to vspipe and vsscript, set_output() in python now takes a second optional alpha clip which will be used for this
fixed avisource leaking one frame reference on destruction
updated plugin list to be more consistent with links to source/binaries and doom9 discussion thread
fixed lut triggering a fatal error when the bits argument is used
fixed regression that prevented alpha output from working in avisource
removed dependency on the now deprecated codecvt header
fixed memory leak where modifyframe wouldn't release the function reference when done
fixed a rare memory leak that could happen if the core was freed before the last frame
fixed a memory leak that would happen if a python videoframe object was instantiated
imwri will no longer write alpha to images unless an alpha clip is specified
improved imwri's input and output format guessing, now integer and float image formats will most likely be returned in native precision
imwri now requires hdri support since it's enabled by default in version 7, as a result of there only being one major configuration the namespace is now always imwri
stackvertical now properly rejects compat formats instead of producing unexpected output
the default initial cache size now also depends on the number of threads used
fixed negative frame request error listing the parent node name instead of the correct name
fixed expr clamping of 9-15 bit output, previously it would clamp to 16bit
fixed corrupted output in expr when mixing int and float for input and output (pinterf)
Myrsloik
28th December 2017, 13:07
I did some more testing and R41-test4 should be considered RC quality.
Myrsloik
30th December 2017, 19:49
R41-RC1 (https://www.dropbox.com/s/raa1xipgzwrwug1/VapourSynth-R41-RC1.exe?dl=1)
Fixes an avisource crash and some minor typos. Also lots of imwri changes but that's a separate thread.
kgrabs
31st December 2017, 17:24
About the BoxBlur thing, there's still a pretty big difference
#Main
from vapoursynth import core, GRAY, YUV, YUV444PS
args = dict(hradius=2, hpasses=1, vradius=2, vpasses=1, planes=[0])
# Use "planes"
clip = core.std.BlankClip(None, 1920, 1080, YUV444PS, 2000, keep=1)
clip = core.std.BoxBlur(clip, **args)
clip.set_output()
# Time elapsed: 0:27.135 - 73.70663065422803583715 FPS
# Split to Gray
clip_yuv = core.std.BlankClip(None, 1920, 1080, YUV444PS, 2000, keep=1)
clip = core.std.ShufflePlanes(clip_yuv, 0, GRAY)
clip = core.std.BoxBlur(clip, **args)
clip = core.std.ShufflePlanes([clip, clip_yuv], [0,1,2], YUV)
clip.set_output()
# Time elapsed: 0:11.011 - 181.64144952606065430700 FPS
The difference isnt as evident with 8 bit though:
Time elapsed: 0:05.794 - 345.20685825648109812391 FPS (split to gray)
Time elapsed: 0:07.107 - 281.39460754565209299471 FPS (use "planes")
PS sry for being lazy and taking like a week to do it :^)
Edit: Rather than also being 73fps like the "use planes" test, changing it to planes=[0,1,2] is actually only about 63fps. PPS I used R41-RC1
Myrsloik
31st December 2017, 18:27
About the BoxBlur thing, there's still a pretty big difference
#Main
from vapoursynth import core, GRAY, YUV, YUV444PS
args = dict(hradius=2, hpasses=1, vradius=2, vpasses=1, planes=[0])
# Use "planes"
clip = core.std.BlankClip(None, 1920, 1080, YUV444PS, 2000, keep=1)
clip = core.std.BoxBlur(clip, **args)
clip.set_output()
# Time elapsed: 0:27.135 - 73.70663065422803583715 FPS
# Split to Gray
clip_yuv = core.std.BlankClip(None, 1920, 1080, YUV444PS, 2000, keep=1)
clip = core.std.ShufflePlanes(clip_yuv, 0, GRAY)
clip = core.std.BoxBlur(clip, **args)
clip = core.std.ShufflePlanes([clip, clip_yuv], [0,1,2], YUV)
clip.set_output()
# Time elapsed: 0:11.011 - 181.64144952606065430700 FPS
The difference isnt as evident with 8 bit though:
Time elapsed: 0:05.794 - 345.20685825648109812391 FPS (split to gray)
Time elapsed: 0:07.107 - 281.39460754565209299471 FPS (use "planes")
PS sry for being lazy and taking like a week to do it :^)
Edit: Rather than also being 73fps like the "use planes" test, changing it to planes=[0,1,2] is actually only about 63fps. PPS I used R41-RC1
Sigh, you're right. I forgot to do the last optimization in the code so all planes are transposed even if no blurring is done to them. Will fix it since it will give nice speedups in many scripts...
Myrsloik
6th January 2018, 22:04
R41 RC2 (https://www.dropbox.com/s/x9lso79z2b6bszz/VapourSynth-R41-RC2.exe?dl=1)
Should fix BoxBlur not copying planes the fastest possible way. Otherwise no real changes from RC1. So test BoxBlur a bit to verify that I got it right.
Myrsloik
9th January 2018, 20:09
R41 released. The usual post about it (http://www.vapoursynth.com/2018/01/r41-less-leaking/). Have fun with less shitty alpha support.
poisondeathray
10th January 2018, 07:53
It’s now possible to pass a second alpha clip to set_output() in scripts and vspipe will output it.
How exactly is the vspipe output for alpha supposed to work ?
How about a solution like this:
clip.set_output(alpha=alpha_clip)
And then it'd be output as GBRAP. Or something like that, thoughts?
Is it like this ?
clip[0].set_output(alpha=clip[1])
vspipe --info reports RGB24
What exactly is COMPATBGR32 ? I know it's for legacy purposes, sometimes RGB flip , but does it carry a valid alpha or is it a "dummy" alpha ? or something completely different. I figured it was remotely similar to "RGB32" in avsiynth-ese
Myrsloik
10th January 2018, 10:56
How exactly is the vspipe output for alpha supposed to work ?
Is it like this ?
clip[0].set_output(alpha=clip[1])
vspipe --info reports RGB24
What exactly is COMPATBGR32 ? I know it's for legacy purposes, sometimes RGB flip , but does it carry a valid alpha or is it a "dummy" alpha ? or something completely different. I figured it was remotely similar to "RGB32" in avsiynth-ese
It works like you guessed. If you check the info output from vspipe it also says "alpha: yes" or something similar.
Compatbgr32 is simply packed bgra with dummy alpha. It only exists for avisynth compatibility reasons.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.