Log in

View Full Version : Vapoursynth


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 [66] 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100

Selur
18th February 2019, 20:14
@asrain:
a. for me it's not about doing a conversion, but seeing the wave front in a preview to make decisions about cutting and chapter points.
b. last I checked eac3to is Windows only and only support a few audio formats and no filtering, so at least for me it's hardly useful. (ffmpeg and sox are way more useful for me)

sl1pkn07
19th February 2019, 17:04
eac3to works almost good with wine

poisondeathray
20th February 2019, 17:49
avfs x64 issue with certain x64 avs scripts ? R45

A simple TIVTC script works ok through avisynth+ x64 , verified in avspmod x64, or vdub2 x64 . But when run though avfs x64, it produces "green screen" . avfs x86 ok


MPEG2Source()
TFM().TDecimate()


YV12 working for both avfs x86, x64 with version yv12, and blankclip yv12

version()
converttoyv12()



blankclip(pixel_type="YV12")




Why does avfs x64 TIVTC script in YV12 not work ? But simple "version" or "blankclip" in YV12 work ?

Even if I remove the x86 dgdecode.dll, tivtc.dll from the avisynth x86 plugins folder to "force" x64 pathway, still
does not work

But different source filter works in x64, TIVTC works, so this suggests the x64 dgdecode compatibility issue with avfs ?

dgdecode.dll x64 was from here
https://www.mediafire.com/download/c0wmemj5jam/DGDecode_3-19-2010.rar
http://avisynth.nl/index.php/AviSynth%2B_x64_plugins


FFVideoSource()
TFM().TDecimate()

Selur
20th February 2019, 17:56
@poisondeathray: I don't see the connection between Avisynth and Vapoursynth here,... (this is the Vapoursynth thread,..)

poisondeathray
20th February 2019, 17:57
@poisondeathray: I don't see the connection between Avisynth and Vapoursynth here,... (this is the Vapoursynth thread,..)

newer avfs versions are from vapoursynth . It's distributed that way. Myrsloik updates and compiles it now. If it's more appropriate, perhaps move discussion over to the avfs thread if some mod wants to move it

Selur
20th February 2019, 18:45
ah okay,...

VS_Fan
21st February 2019, 04:02
avfs x64 issue with certain x64 avs scripts ? R45

Why does avfs x64 TIVTC script in YV12 not work ? Have you tried:

Mpeg2DecPlus (source (https://github.com/chikuzen/MPEG2DecPlus) binary (https://kuroko.fushizen.eu/bin/mpeg2decplus-0.1.1.zip)) instead of DGdecode?
The latest TIVTC v1.0.14 (https://github.com/pinterf/TIVTC/releases) from pinterf ?
Setting fps with AssumeFPS("ntsc_video") before TFM ?

poisondeathray
21st February 2019, 04:16
Have you tried:
[LIST]
Mpeg2DecPlus (source (https://github.com/chikuzen/MPEG2DecPlus) binary (https://kuroko.fushizen.eu/bin/mpeg2decplus-0.1.1.zip)) instead of DGdecode?

Thanks, it works ok now with this version

The problem was the version of dgdecode.dll x64 I linked to earlier

Selur
23rd February 2019, 08:45
Using a 1280x720 source and:
# Imports
import os
import sys
import vapoursynth as vs
core = vs.get_core()
# Import scripts folder
scriptPath = 'I:/Hybrid/64bit/vsscripts'
sys.path.append(os.path.abspath(scriptPath))
# Loading Plugins
core.std.LoadPlugin(path="I:/Hybrid/64bit/vsfilters/Support/libmvtools.dll")
core.std.LoadPlugin(path="I:/Hybrid/64bit/vsfilters/DeCrawlFilter/DotKill/dotkill64.dll")
core.std.LoadPlugin(path="I:/Hybrid/64bit/vsfilters/SourceFilter/LSmashSource/vslsmashsource.dll")
# Import scripts
import hysteria
import hnwvsfunc
import mvsfunc
# Loading E:\to convert\test.mkv using LWLibavSource
clip = core.lsmas.LWLibavSource(source="E:\to convert\test.mkv", format="YUV420P8", cache=0)
# making sure input color matrix is set as unspec
clip = core.resize.Point(clip, matrix_in_s="unspec",range_s="limited")
# making sure frame rate is set to 24000/1001
clip = core.std.AssumeFPS(clip, fpsnum=24000, fpsden=1001)
# Setting color range to TV (limited) range.
clip = core.std.SetFrameProp(clip=clip, prop="_ColorRange", intval=1)
# DeCrawling using DotKill
clip = core.dotkill.DotKill(clip=clip, napply=3)
# removing grain using MLDegrain
clip = hnwvsfunc.MLDegrain(clip=clip, soft=[0,0,0])
# sharpening using FineSharp
clip = hnwvsfunc.FineSharp(clip=clip)
# line darkening using Hysteria
clip = hysteria.Hysteria(clip=clip,highthresh=10)
# Output
clip.set_output()
the memory usage is sky rocketing,... after ~10min, the RAM usage is > 11 GB and still increasing (15min 13GB+, 20min 16G+).
Is this something on my system, a known problem, or should I do some more testing and test these filters one by one?


Cu Selur

Ps.: What's the recommend way to limit the RAM usage?
PPs.: With growing memory usage 18GB+ now the CPU usage also drops, so this probably is one of the filters using more and more RAM and slowing down while handling that RAM.


=> GOT IT, problem is with DotKill, updating to the latest version of DotKill fixed it.

_Al_
24th February 2019, 01:46
Same is hapening with QTGMC (havsfunc) and there might be others. I just simply tell Vapoursynth to limit RAM,
some cross platform method, like in python:
mem = psutil.virtual_memory()
available = int(mem.available/1024/1024) #MB
cache = available - some_wiggle_room_value
core.max_cache_size = cache
Vapoursynth then releases RAM, if I watch usage it goes all the way to the limit and then it is drastically released. It cycles like that for a some short time - filled/released,filled/released but strangely, after some short time, it settles somewhere underneath that set limit. Almost like someone wrote that in some intelligent way, or it is a coincidence, not sure.

Selur
24th February 2019, 08:05
It's probably some filter with a memory leak.
Memory consumption doesn't run amok here when using 'QTGMC(Input=clip, Preset="Fast", TFF=True, opencl=True)', stays at around 4.3GB for Blu-ray content.
What QTGMC setting do you use?

Cu Selur

_Al_
24th February 2019, 20:37
Just Preset = "Slow"and TFF=True, but I am not complaining because I test things on my laptops which have ridiculous 4GB RAM. On the contrary by limiting RAM I am surprised that it works. Mostly there is about 1GB available for Vapoursynth. Sure performance is perhaps severely limited. Not sure now about workstation, but anyway for all scripts I limit RAM usage first, checking how much is available and setting available cache as a rule. So I might not even know, if RAM was leaking somewhere. I do not know how much control can Vapoursynth have above all those DLL's out there. Scripts are not crashing so I gather it kind of works.

poisondeathray
25th February 2019, 16:17
Same is hapening with QTGMC (havsfunc) and there might be others. I just simply tell Vapoursynth to limit RAM,
some cross platform method, like in python:
mem = psutil.virtual_memory()
available = int(mem.available/1024/1024) #MB
cache = available - some_wiggle_room_value
core.max_cache_size = cache
Vapoursynth then releases RAM, if I watch usage it goes all the way to the limit and then it is drastically released. It cycles like that for a some short time - filled/released,filled/released but strangely, after some short time, it settles somewhere underneath that set limit. Almost like someone wrote that in some intelligent way, or it is a coincidence, not sure.



I can't reproduce on x64 after 10 min . It just hovers around 1.2-1.3 GB RAM . Does not have characteristics of a memory leak

Maybe a problem with one of your plugin/filter dependencies ?

_Al_
2nd March 2019, 19:06
There might be, I'm also one version behind with Vapoursyth and Python 3.6. Simple script to deinterlace avchd.M2TS with about 1GB available, it takes about couple of seconds to freeze. If cache is limited, no problem.
file = r'C:\vid\avchd.M2TS'
from vapoursynth import core
import havsfunc as haf
#core.max_cache_size = 800 #this works
clip = core.lsmas.LWLibavSource(file)
clip = haf.QTGMC(clip, Preset='Slow', TFF=True)
clip.set_output()

asarian
2nd March 2019, 20:27
It's probably some filter with a memory leak.
Memory consumption doesn't run amok here when using 'QTGMC(Input=clip, Preset="Fast", TFF=True, opencl=True)', stays at around 4.3GB for Blu-ray content.
What QTGMC setting do you use?

Cu Selur


No memory leaks here on my end whatsoever. And I use QTGMC on a daily basis.

P.S. I see you're using 'opencl=True'. Interesting. :) Shouldn't be needed when you have 'Denoiser="KNLMeansCL"' in the parameters, though, right? Or does it something else too?

jackoneill
2nd March 2019, 22:29
There might be, I'm also one version behind with Vapoursyth and Python 3.6. Simple script to deinterlace avchd.M2TS with about 1GB available, it takes about couple of seconds to freeze. If cache is limited, no problem.
file = r'C:\vid\avchd.M2TS'
from vapoursynth import core
import havsfunc as haf
#core.max_cache_size = 800 #this works
clip = core.lsmas.LWLibavSource(file)
clip = haf.QTGMC(clip, Preset='Slow', TFF=True)
clip.set_output()

with about 1GB available

VapourSynth's cache will try to use more than that with high resolutions and complex scripts (QTGMC), at least until a few hundred frames have been processed. Then the cache figures out it doesn't need so much memory.

(The default max_cache_size is 4 GB on 64 bit systems and 1 GB on 32 bit systems.)

_Al_
3rd March 2019, 01:39
thanks, did not realize that simple print(core.max_cache_size) could give it away, which indeed gives 4096

Selur
3rd March 2019, 09:04
Shouldn't be needed when you have 'Denoiser="KNLMeansCL"' in the parameters, though, right? Or does it something else too?
OpenCL = True causes QTGMC to use NNEDI3CL instead of znedi3 (not sure atm. whether I did this modification myself in https://github.com/Selur/VapoursynthScriptsInHybrid/blob/master/havsfunc.py or not :))

asarian
3rd March 2019, 11:43
OpenCL = True causes QTGMC to use NNEDI3CL instead of znedi3 (not sure atm. whether I did this modification myself in https://github.com/Selur/VapoursynthScriptsInHybrid/blob/master/havsfunc.py or not :))

:thanks: Every cycle shaved off is one.

Dogway
4th March 2019, 15:31
Is there a way to indicate Script path location? I'm using VS in portable mode but VSEdit can't find the modules. I tried placing vapoursynth_modules.pth and sitecustomize.py in root folder but still no luck.

ChaosKing
4th March 2019, 15:40
One way is to append a path in python in your script:
scriptPath = os.getcwd() + "/../scripts"
sys.path.append(os.path.abspath(scriptPath))

Usually you can place scripts here: C:\Python37\Lib\site-packages\vapoursynth

If you're using a python embedded zip you can set a path in python37._pth

Dogway
4th March 2019, 16:08
I'm unable to load them, my scripts are in "C:\Program Files (x86)\VapourSynth_R45(x64)\vapoursynth64\scripts"
so I write in python37._pth the following.
vapoursynth64\scripts
Scripts
Lib\site-packages
python37.zip
.

# Uncomment to run site.main() automatically
#import site

For the script I write:
import vapoursynth as vs
import havsfunc as haf

core = vs.get_core()

clip = core.ffms2.Source(r'D:\source.mp4')
clip = core.haf.SMDegrain(clip)
clip.set_output()

Edit: I'm the admin, so I have write access to Program Files.

Edit2: Ok, ok, it's clip = haf.SMDegrain(clip) without the core.

ChaosKing
4th March 2019, 16:54
And where is your python installation located? Have you tried with a full path?

Dogway
4th March 2019, 17:27
It's inside VapourSynth_R45(x64), embedded. It worked I just had to omit the core. namespace.
Too bad I didn't find your fatpack earlier, should be sticky. I will probably change to that once you update it to 2019 version.

I have a question though. When you load avisynth plugins or scripts into VapourSynth, will the performance be limited to that of avisynth or you get the benefits of better VS multithreading?

ChaosKing
4th March 2019, 17:34
Depends on the plugin. You will often see a msg with something like using slow method blah blah. Solution: use avsw.Eval() instead.

asarian
13th March 2019, 11:36
Odd. I have a source file of 624x354. But getting the following returned:

... line 3159, in MCTemporalDenoise
return core.std.Crop(smP, **crop_args)
File "src\cython\vapoursynth.pyx", line 1833, in vapoursynth.Function.__call__
vapoursynth.Error: Crop: cropped area needs to have mod 2 height offset

Wait, 354 is mod2, right?! Or am I going crazy? :)

Myrsloik
13th March 2019, 11:38
Odd. I have a source file of 624x354. But getting the following returned:

... line 3159, in MCTemporalDenoise
return core.std.Crop(smP, **crop_args)
File "src\cython\vapoursynth.pyx", line 1833, in vapoursynth.Function.__call__
vapoursynth.Error: Crop: cropped area needs to have mod 2 height offset

Wait, 354 is mod2, right?! Or am I going crazy? :)

You have to add a print at the point where it happens. The internal clip that's cropped in MCTemporalDenoise isn't necessarily the same as the input.

asarian
13th March 2019, 11:47
You have to add a print at the point where it happens. The internal clip that's cropped in MCTemporalDenoise isn't necessarily the same as the input.

Didn't realize that. :) :thanks:

Since this pertains to a pre-cropped area of a larger, 1080p source (so I can 'Oyster' it in several parts), I tried a 356 swatch, which didn't generate the error. So, I'll just go with that (it's mainly an overscan area anyway, as I only need a 346 height).

_Al_
14th March 2019, 22:07
Encoding using clip.output() right from vapoursynth script itself, where input video is ANY anamorphic video like HDV camcorder M2T video or NTSC DV or VOB gives jagged lines. As soon as there is resize involved , say to square pixel it is OK. If some odd resize is given , say 1000,600, again it might fail and jagged lines appear. That is not that important though because square pixel , resize to 16:9 (M2T video) or 4:3 (DVavi, VOB) seem to work. It encodes alright. Point is, without resize, just using SAR flag in encoder, gives jagged lines as presented in attachment.
Interlacing seem have nothing to do with it, using QTGMC or even assuming it as progressive using setFrameProp would not help. This behavior is also same using different source plugins.
import vapoursynth as vs
from vapoursynth import core
d2v_file = r"path to file ..."
clip = core.d2v.Source(d2v_file) #sourse was mpeg2 HDV camcorder video
import subprocess
import shutil
output = r'F:/Destination/test.264'

x264 = shutil.which('x264')
x264_cmd = [x264, '--frames', f'{len(clip)}',
'--input-csp', 'i420',
'--demuxer', 'raw',
'--sar', '4:3',
'--input-depth', '8',
'--input-res', f'{clip.width}x{clip.height}',
'--fps', f'{clip.fps_num}/{clip.fps_den}',
'--crf', '18',
'--colorprim', 'bt709',
'--transfer', 'bt709',
'--colormatrix', 'bt709',
'--output', output,
'-']
process = subprocess.Popen(x264_cmd, stdin=subprocess.PIPE, stdout=subprocess.PIPE)
clip.output(process.stdin)
process.communicate()

for x265 the same:
x265_cmd = [x265, '--frames', f'{len(clip)}',
#'--input-csp', 'i420',
'--y4m',
'--input-depth', f'{clip.format.bits_per_sample}',
'--output-depth', f'{clip.format.bits_per_sample}',
'--input-res', f'{clip.width}x{clip.height}',
'--fps', f'{clip.fps_num}/{clip.fps_den}',
'--crf', f'{str(crf)}',
'--output', output,
'-']

process = subprocess.Popen(x265_cmd, stdin=subprocess.PIPE, stdout=subprocess.PIPE)
clip.output(process.stdin, y4m = True, progress_update=progressupdate)
process.communicate()
Previewing script is always ok, encoding within VSEditor also, just not directly using that output() function.

_Al_
15th March 2019, 07:00
I might found a culprit, but not sure what to do with it or how to fix it.

for example NTSC video there is 1 byte per sample, if I get_stride for all three planes:
f = clip.get_frame(0)
print(f.get_stride(0),f.get_stride(1),f.get_stride(2))
I get:
736 384 384 (expected: 720 360 360)
for HDV video from HDV tape camcorder (shooting 1440x1080) I get:
1440 736 736 (expected: 1440 720 720)

after resize I get even values, like resizing NTSC video to 640x480 I'd get:
640 320 320
or resizing that HDV video to 1920x1080, I'd get:
1920 960 960

Those are expected numbers and encoding is also ok, so this looks like a cause to offset the output if resizing is not done. If I resize to the same resolution values stay the same, it would not help.

Is there any way to get those values even without resizing? What are those data that are trailing (or preceding) each line in plane array? If it is not stride itself (wrong value) that offsets things.

jackoneill
15th March 2019, 13:16
I might found a culprit, but not sure what to do with it or how to fix it.

for example NTSC video there is 1 byte per sample, if I get_stride for all three planes:
f = clip.get_frame(0)
print(f.get_stride(0),f.get_stride(1),f.get_stride(2))
I get:
736 384 384 (expected: 720 360 360)
for HDV video from HDV tape camcorder (shooting 1440x1080) I get:
1440 736 736 (expected: 1440 720 720)

after resize I get even values, like resizing NTSC video to 640x480 I'd get:
640 320 320
or resizing that HDV video to 1920x1080, I'd get:
1920 960 960

Those are expected numbers and encoding is also ok, so this looks like a cause to offset the output if resizing is not done. If I resize to the same resolution values stay the same, it would not help.

Is there any way to get those values even without resizing? What are those data that are trailing (or preceding) each line in plane array? If it is not stride itself (wrong value) that offsets things.

This is a known bug which will be fixed in the next release.

There was a bit of code in clip.output() which assumed that the width multiplied by bytes_per_sample is the same as the stride. This is only true when the width multiplied by bytes_per_sample is a multiple of 32.

This is why you have a problem with 720x___ but not with 1280x___, 1440x____ or 1920x____. 720 / 32 = 22.5; 1280 / 32 = 40; 1440 / 32 = 45; 1920 / 32 = 60.

The stride (the distance between two consecutive rows) is not always the same as the width multiplied by bytes_per_sample in order to make every row start at a memory location which is a multiple of 32. (The first row starts at a multiple of 32 because that's what VapourSynth requests from the memory allocator.) This apparently makes filters run faster. The extra (stride - width * bytes_per_sample) bytes are left unused.

_Al_
15th March 2019, 18:50
Thank you for explanation, now when it is clear it is even workable.

Width for output() function now has to be any even number x 32. Multiple of odd number would not work. So any width divided by 32 with even result would work.
Thank you.

Myrsloik
15th March 2019, 21:24
Thank you for explanation, now when it is clear it is even workable.

Width for output() function now has to be any even number x 32. Multiple of odd number would not work. So any width divided by 32 with even result would work.
Thank you.

This will be fixed in the next release

_Al_
15th March 2019, 21:36
Thank you,
that direct export is a fantastic feature where even progress update is available

asarian
16th March 2019, 00:14
Encoding using clip.output() right from vapoursynth script itself, where input video is ANY anamorphic video like HDV camcorder M2T video or NTSC DV or VOB gives jagged lines....

Some interesting script files you have there. :) Speaking of which, is there a variable for the running script name itself?

_Al_
16th March 2019, 01:02
Not sure if I understand, do you want to give it output name as script name?
You'd use __file__ variable, if you want just basename, you'd do something like:
import os
output_dir = r'F:\Destination'
output = os.path.join(output_dir, os.path.basename(__file__)+'.264')

In practical terms you'd perhaps always import your modul for encoding, you'd put that encoding part as a separate py file and put it in Python\Lib\vapoursynth directory and just import it as a modul in each script and run it. You couldpass the whole cmd line as a variable string and let that sorted out in that modul with shlex.split(cmd as a string) etc.

asarian
16th March 2019, 01:38
Not sure if I understand, do you want to give it output name as script name?
You'd use __file__ variable, if you want just basename, you'd do something like:
import os
output_dir = r'F:\Destination'
output = os.path.join(output_dir, os.path.basename(__file__)+'.264')

^^ That's exactly what I wanted to do! :) :thanks:

asarian
16th March 2019, 11:16
Thank you,
that direct export is a fantastic feature where even progress update is available

So, how do you call the script?! When I just try

'VSPipe f:\jobs\test.vpy'

It tells me 'No output file specified'

I must be doing it wrong. :)

_Al_
16th March 2019, 20:22
vspipe is another (perhaps preferred) way how to encode your script. It pipes frames into an encoder of your choice from OUTSIDE of vapoursynth script *.vpy or *.py,

but method from above, vapoursynth outpus raw frames directly from script itself, you bypass vspipe, but you need to have *.py, not *.vpy because you run Python basically , vapoursynth does its wrapping part in Python and serving frames with clip.output(). You just run script itself with this method and it will start encoding, you can choose a python consol of your choice (IDLE for example came with Python, so you should have it) and pressing F5 or even using VSEditor, but VS Editor needs clip.set_output(), otherwise it would not let script run, therefore encode (and then showing preview). If you want to avoid preview popup after encoding, you'd just evaluate script.

if you do not use a console and prefer windows command line, you'd need to run:
python3 "test.py"
or
python "test.py"

ChaosKing
17th March 2019, 14:36
Why is the avisynth RemoveDirt.dll only availible if the RemoveDirtVS_x64.dll is not autoloaded.

My steps
core.avs.LoadPlugin(r"D:\avs_plugins64\RemoveDirt.dll") # no loading error
But clip = core.avs.RestoreMotionBlocks(clip) is not availible

Checking with print(core.get_plugins()) confirms that com.fakeurl.removedirtvs is loaded but nothing with avisynth.

Now without RemoveDirtVS_x64.dll
core.avs.LoadPlugin(r"D:\avs_plugins64\RemoveDirt.dll")
print(core.get_plugins()) -> RestoreMotionBlocks is available 'com.vapoursynth.avisynth': {'namespace': 'avs', 'identifier': 'com.vapoursynth.avisynth', 'name': 'VapourSynth Avisynth Compatibility', 'functions': {'LoadPlugin': 'path:data;', 'RestoreMotionBlocks': 'c1:clip;c2:clip ...

So why is VS-RemoveDirt blocking the avisynth RemoveDirt functions?


VS and AVS dlls: https://www.dropbox.com/s/nkho8s2pjeuydqq/RemoveDirtVS.zip?dl=1

Iron_Mike
18th March 2019, 04:24
is it possible to output the version number of a loaded VS plugin ? if so, what is the command ?

Thanks.

Myrsloik
18th March 2019, 10:39
is it possible to output the version number of a loaded VS plugin ? if so, what is the command ?

Thanks.

There are no exported version numbers

asarian
18th March 2019, 22:47
vspipe is another (perhaps preferred) way how to encode your script. It pipes frames into an encoder of your choice from OUTSIDE of vapoursynth script *.vpy or *.py,

but method from above, vapoursynth outpus raw frames directly from script itself, you bypass vspipe, but you need to have *.py, not *.vpy because you run Python basically , vapoursynth does its wrapping part in Python and serving frames with clip.output(). You just run script itself with this method and it will start encoding, you can choose a python consol of your choice (IDLE for example came with Python, so you should have it) and pressing F5 or even using VSEditor, but VS Editor needs clip.set_output(), otherwise it would not let script run, therefore encode (and then showing preview). If you want to avoid preview popup after encoding, you'd just evaluate script.

if you do not use a console and prefer windows command line, you'd need to run:
python3 "test.py"
or
python "test.py"


Thank you! :)

ChaosKing
19th March 2019, 01:16
I have this "prop transfer" code:
def _Transfer(n, f):
fout = f[0].copy()
fout.props['_Diff'] = f[1].props['_Diff']
return fout
alt_clip = core.std.ModifyFrame(alt_clip, [alt_clip, alt_clip_butt], selector=_Transfer)
Is it possible to make _Transfer() more universal, like this _Transfer(n, f, prop_name), so I can pass any prop -> f[1].props[prop_name] ? If yes, how to call/pass it?

@Myrsloik have you seen my RemoveDirt post? https://forum.doom9.org/showthread.php?p=1869151#post1869151

WolframRhodium
19th March 2019, 05:13
I have this "prop transfer" code:
def _Transfer(n, f):
fout = f[0].copy()
fout.props['_Diff'] = f[1].props['_Diff']
return fout
alt_clip = core.std.ModifyFrame(alt_clip, [alt_clip, alt_clip_butt], selector=_Transfer)
Is it possible to make _Transfer() more universal, like this _Transfer(n, f, prop_name), so I can pass any prop -> f[1].props[prop_name] ? If yes, how to call/pass it?



from functools import partial

def _Transfer(n, f, prop_name):
fout = f[0].copy()
fout.props[prop_name] = f[1].props[prop_name]
return fout
alt_clip = core.std.ModifyFrame(alt_clip, [alt_clip, alt_clip_butt], selector=partial(_Transfer, prop_name="_Diff"))

ChaosKing
19th March 2019, 10:44
Exactly what I wanted, perfect :thanks:

lansing
19th March 2019, 15:07
When I try to extract planes and merge them back together, I got error "ShufflePlanes: Plane 1 and 2 are not subsampled multiples of first plane"?


clip_yuv16 = core.resize.Bicubic(clip, format=vs.YUV420P16)

y_clip = core.std.ShufflePlanes(clip_yuv16 , planes=0, colorfamily=vs.YUV)
u_clip = core.std.ShufflePlanes(clip_yuv16 , planes=1, colorfamily=vs.YUV)
v_clip = core.std.ShufflePlanes(clip_yuv16 , planes=2, colorfamily=vs.YUV)

yuv16_new = core.std.ShufflePlanes(clips=[y_clip, u_clip, v_clip], planes=[0,0,0], colorfamily=vs.YUV)

Wolfberry
19th March 2019, 15:35
When I try to extract planes and merge them back together, I got error "ShufflePlanes: Plane 1 and 2 are not subsampled multiples of first plane"?


clip_yuv16 = core.resize.Bicubic(clip, format=vs.YUV420P16)

y_clip = core.std.ShufflePlanes(clip_yuv16 , planes=0, colorfamily=vs.YUV) ←
u_clip = core.std.ShufflePlanes(clip_yuv16 , planes=1, colorfamily=vs.YUV) ←
v_clip = core.std.ShufflePlanes(clip_yuv16 , planes=2, colorfamily=vs.YUV) ←

yuv16_new = core.std.ShufflePlanes(clips=[y_clip, u_clip, v_clip], planes=[0,0,0], colorfamily=vs.YUV)


You need to use GRAY (not YUV) if you want to extract individual planes.

lansing
19th March 2019, 15:51
You need to use GRAY (not YUV) if you want to extract individual planes.

Thanks it works

Selur
27th March 2019, 20:17
I'm wondering could someone adjust https://github.com/HENDRIX-ZT2/Deep-Video-Deinterlacing to be used as a Vapoursynth filter? sounds interesting,..