Vapoursynth

[sl1pkn07]

for example, in my encode scripts with avisynth in my linux, call avs2pipe before encode and extract number of frames and WxH from output and parse to x264. and with avs2yuv (asv2pipe and avs2pipemod don't silence his output) process the video


x264="/path/of/x264/
cmd="$(<x264_commands)"
info="$(wine avs2pipe --info "$1")"
frames="$(echo -n "$info" | sed -ne 's/^v:frames\(.*\)$/\1/p' | sed 's|[\r ]||g')"
res+="$(echo -n "$info" | sed -ne 's/^v:width\(.*\)$/\1/p' | sed 's|[\r ]||g')"
res+="x"
res+="$(echo -n "$info" | sed -ne 's/^v:height\(.*\)$/\1/p' | sed 's|[\r ]||g')"

wine avs2yuv "$1" -o - | "$x264" - --output "$2" --stdin y4m --frames "$frames" --input-res "$res" $cmd


./encode archive.avs vid.mkv

(x264_commands: is a file with x264 parmeters for encode)

i supposed with vapoursynth its the same method, but swap "wine avs2yuv" to "python script.py" command

in win make a .bat with same process and running xd

greetings

[ChaosKing]

detect_framecount.py
This will print the number of frames :

import vapoursynth as vs
import sys
core = vs.Core(threads = 6)
c = core.avisource.AVISource(r'e:\P4_14.avi')
print("Number of frames: ", c.num_frames) # or just print(c.num_frames)




And you can also do thinks like this:

import vapoursynth as vs
import sys
import os
core = vs.Core(threads = 6)
c = core.avisource.AVISource(r'e:\P4_14.avi')
print("Number of frames: ", c.num_frames) # or just print(c.num_frames)
os.system("calc") # or your x264 call...


But I'm not a python coder so maybe there is a better way

@sl1pkn07, I think the combination with wine will slow down your encode unnecessarily

[LoRd_MuldeR]

ChaosKing, the problem is that modifying the original script will not be possible/desirable.

What I need is a Python script that will load an existing VapourSynth script (which is provided by the user and which will be piped into x264 as-is) and from that script detect the total frame count.

I know I can use imp.load_source() to load the VPY script, but I don't really know what to do with it...

[Myrsloik]

ChaosKing, the problem is that modifying the original script will not be possible.

What I need is a Python script that will load an existing VapourSynth script (which is provided by the user) and from that script detect the total frame count.

It will kinda improve in the next version/not so distant future. The clip.output() stuff will go since it's just unnecessarily complicated and will be replaced with a standard program to pipe the output. So if you're not in a hurry it should solve itself in a bit. The main problem is that if someone uses clip.output() you have to rewrite the script to get the number of frames...

[LoRd_MuldeR]

It will kinda improve in the next version/not so distant future. The clip.output() stuff will go since it's just unnecessarily complicated and will be replaced with a standard program to pipe the output.

That would be nice :)

Ideally that "standard program" would write the data to the STDOUT and, at the same time, print some basic info (including total frame count) onto the STDERR.

And it would also have a switch to only print the info but not output anything.

So if you're not in a hurry it should solve itself in a bit.

Well it's the thing that's currently blocking me for properly integrating VapourSynth into my x264 GUI. But it surly can wait a few more days.

The main problem is that if someone uses clip.output() you have to rewrite the script to get the number of frames...

Yup, that's the problem. And re-writing is not easy to do, because I cannot expect the user's script to be in a specific form...

[Adub]

Myrsloik, do you have a coding style that you prefer we stick to when hacking around in the core? Similar to libav's coding rules (https://libav.org/developer.html#toc-Code-formatting-conventions)?

[Myrsloik]

Myrsloik, do you have a coding style that you prefer we stick to when hacking around in the core? Similar to libav's coding rules (https://libav.org/developer.html#toc-Code-formatting-conventions)?

Qt inspired with hints of pascal verbosity?

You can probably see the pattern in all the existing code and try to copy it.

[Adub]

Okay, I figured it would be something like that.

I asked because I was considering throwing together a basic indent command line to make sure I didn't miss violations from time to time. I've been following your style as far as I've paid attention to so far, so I just wanted to make sure that any possible merges would work just fine.

[Adub]

Myrsloik, how exactly does the "struct VSAPI" definition in vapoursynth.pxd relate to the "const vsapi" initialization in vsapi.cpp?

I though at first that it was a direct 1:1 mapping between API functions, but now I'm not so sure. Does order not matter when adding a new function to both of these?

For reference, I'm adding a new function, transferVideoFrame(), that can be used by video filters to transfer frame data between the host memory and GPU memory.

Forgive me if this is a stupid question, I just have little familiarity with the Cython integration layer.

Edit I see that the full API is declared in Vapoursynth.h, but I'm still wondering about the .pxd typedef.

[Myrsloik]

Cython is a bit special. The pxd is just says that a function/data structure with something kinda like this or that exists. For the actual compilation cython still includes vapoursynth.h and uses its definitions directly. If you look some more you'll also see that cython doesn't have the const keyword.

In theory its definitions should match vapoursynth.h but it doesn't really matter that much as long as it compiles.

[Adub]

Okay, interesting (and freakin' odd). Thanks for the explanation, Myrsloik! I'll crack on with Vapoursynth.h and vsapi.cpp.

[LoRd_MuldeR]

It will kinda improve in the next version/not so distant future. The clip.output() stuff will go since it's just unnecessarily complicated and will be replaced with a standard program to pipe the output.

Sorry for my impatience, but any news on that yet?

[Myrsloik]

Sorry for my impatience, but any news on that yet?

Not really, real life has intervened. This time I don't even dare to guess when stuff will be done...

[mp3dom]

I'm getting errors while opening a MOV with "Animation RLE" as a codec.
Using FFMS2 (both version, found here: http://forum.doom9.org/showpost.php?p=1607732&postcount=1739) the error is:

Traceback (most recent call last):
File "<pyshell#6>", line 1, in <module>
vid=core.ffms2.Source(source='vid_23976fps.mov')
File "vapoursynthpp.pyx", line 1048, in vapoursynth.Function.__call__ (src\cython\vapoursynthpp.c:15779)
vapoursynth.Error: 'Source: No suitable output format found'


The output format should be (I guess) RGB32.
Using the FFMS2 version compiled also for AviSynth (the second link) in AviSynth, doesn't throw any error and correctly open the file as RGB32.

[Adub]

Hmmm, looking at VapourSynth.h, there doesn't appear to be a corresponding VSPresetFormat for RGB32.

Do you have a small sample of your problem clip?

Edit: Ahh, I see that CompatBGR32 is what is used instead.

[Myrsloik]

I'm getting errors while opening a MOV with "Animation RLE" as a codec.
Using FFMS2 (both version, found here: http://forum.doom9.org/showpost.php?p=1607732&postcount=1739) the error is:

Traceback (most recent call last):
File "<pyshell#6>", line 1, in <module>
vid=core.ffms2.Source(source='vid_23976fps.mov')
File "vapoursynthpp.pyx", line 1048, in vapoursynth.Function.__call__ (src\cython\vapoursynthpp.c:15779)
vapoursynth.Error: 'Source: No suitable output format found'


The output format should be (I guess) RGB32.
Using the FFMS2 version compiled also for AviSynth (the second link) in AviSynth, doesn't throw any error and correctly open the file as RGB32.

This is pure speculation but swscale couldn't do all planar<>packed rgb conversions properly until very recently. Internally all rgb needs to be planar for vs Maybe if you try with a newer compile of ffms2. I could be wrong too...

[Reel.Deel]

Hi Myrsloik, here comes a long post. :)
I recently tested a handful of plugins to see which ones display the following warning.
Avisynth Compat: requested frame xxx not prefetched, using slow method that may deadlock

This is the script I used for all of the plugins tested. All plugins tested with default values, using VapourSynth R18 on WinXP (SP3).
import vapoursynth as vs
core = vs.Core(threads=4)

# Plugins
core.avs.LoadPlugin(path=r'C:\DGDecodeNV.dll')
core.avs.LoadPlugin(path=r'C:\WhateveAVSplugin.dll')

# Source
src = core.avs.DGSource(dgi=r'C:\blu-ray 1080p.dgi')

# For plugins that only work in YUY2
#src = core.resize.Point(clip=src, format=vs.COMPATYUY2)

# Processing
src = core.avs.WhateverName(c1=src)

# VDub ouput
last = src
I then, loaded the VS script using AVISourve in AVS and used AVSMeter (http://forum.doom9.org/showthread.php?t=165528&highlight=AVSMETER) to see if the warning would be displayed.

Here's a list of plugins that need to be added to the prefetch list. (http://code.google.com/p/vapoursynth/source/browse/trunk/src/avisynth/avisynth_compat.cpp#188)

checkmate (http://forum.doom9.org/showthread.php?p=1571520#post1571520)
DeCrawl (http://avisynth.org/warpenterprises/#DeCrawl)
DeCross (http://nullinfo.s21.xrea.com/#DeCross)
DeDot (http://nullinfo.s21.xrea.com/#DeDot_YV12)
DeGrainMedian (http://avisynth.org.ru/degrain/degrainmedian.html)
dw3DNR (http://www5e.biglobe.ne.jp/~hoe/dv-and-movie/tipsxxx/index.html)
FluxSmooth (http://forum.doom9.org/showthread.php?t=38296)
frfun7 (http://web.archive.org/web/20080905123941/http://soulhunter.chronocrossdev.com/#002)
NoMoSmooth (http://avisynth.org.ru/docs/english/externalfilters/nomosmooth.htm)
PNLM (http://sky.geocities.jp/apechironnup/junk.html)
SVPFlow (http://forum.doom9.org/showthread.php?t=164554)
TempLinearApproximate (http://forum.doom9.org/showthread.php?t=167032)
TTempSmooth (http://bengal.missouri.edu/~kes25c/)

checkmate(c1:clip; thr:int:opt; max:int:opt; tthr2:int:opt;)
DeCrawl(c1:clip; ythresht:int:opt; ythreshs:int:opt; cthresh:int:opt; temporal:int:opt; spatial:int:opt; spatialpasses:int:opt;)
DeCross(c1:clip; ThresholdY:int:opt; Noise:int:opt; Margin:int:opt; Debug:int:opt;)
DeDot(c1:clip; luma2d:int:opt; lumaT:int:opt; chromaT1:int:opt; chromaT2:int:opt;)
DeGrainMedian(c1:clip; limitY:int:opt; limitUV:int:opt; mode:int:opt; interlaced:int:opt; norow:int:opt;)
dw3DNR(c1:clip; st:float:opt; y:int:opt; uv:int:opt; th:float:opt; sel:int:opt; debug:int:opt;)
FluxSmoothST(c1:clip; temporal_threshold:int:opt; spatial_threshold:int:opt;)
FluxSmoothT(c1:clip; temporal_threshold:int:opt;)
frfun7(c1:clip; lambda:float:opt; T:float:opt; Tuv:float:opt;)hqdn3d(c1:clip; ls:float:opt; cs:float:opt; lt:float:opt; ct:float:opt; restart:int:opt;)
NoMoSmooth(c1:clip; motion_threshold:int:opt; temporal_radius:int:opt; temporal_threshold:int:opt; spatial_radius:int:opt; spatial_threshold:int:opt; show:int:opt;)
PNLM(c1:clip; strength:int:opt; wspan:int:opt; tspan:int:opt; threads:int:opt; opt:int:opt;)
PNLM2(c1:clip; strength:int:opt; wspan:int:opt; tspan:int:opt; selfw:int:opt; angw:int:opt; threads:int:opt; opt:int:opt;)
SVAnalyse(c1:clip; s2:data; src:clip:opt;) # Needs to be added to the prefetch list.
SVConvert(c1:clip; isb:int:opt;) # Prefetch warning unknown because SVAnalyse has to called prior to this.
SVSmoothFps(c1:clip; c2:clip; c3:clip; s4:data; url:data:opt; sar:float:opt; mt:int:opt;) # Prefetch warning unknown because SVAnalyse has to called prior to this.
SVSuper(c1:clip; s2:data;) # By itself it does not display prefetch warning.
TempLinearApproximate(c1:clip; radius:int:opt; plane:int:opt;)
TTempSmooth(c1:clip; maxr:int:opt; lthresh:int:opt; cthresh:int:opt; lmdiff:int:opt; cmdiff:int:opt; strength:int:opt; scthresh:float:opt; fp:int:opt; vis_blur:int:opt;
debug:int:opt; interlaced:int:opt; pfclip:clip:opt;)
TTempSmoothF(c1:clip; maxr:int:opt; lthresh:int:opt; cthresh:int:opt; strength:int:opt; scthresh:float:opt; fp:int:opt; vis_blur:int:opt;
debug:int:opt; interlaced:int:opt; pfclip:clip:opt;)



Here's a list of the filters that currently do not work with VapourSynth.


Bifrost (http://ivtc.org/avisynth/)
TComb (http://bengal.missouri.edu/~kes25c/)

Error:
Invoke not fully implemented, tried to call: SeparateFields but I will pretend it doesn't exist
Avisynth Error: escaped IScriptEnvironment::NotFound exceptions are non-recoverable, crashing...
TComb(c1:clip; mode:int:opt; fthreshL:int:opt; fthreshC:int:opt; othreshL:int:opt; othreshC:int:opt; map:int:opt; scthresh:float:opt; debug:int:opt; opt:int:opt;)
Bifrost(c1:clip; altclip:clip:opt; scenelumathresh:float:opt; variation:int:opt; conservativemask:int:opt; interlaced:int:opt;)




MipSmooth (http://forum.doom9.org/showthread.php?p=760915#post760915)
* Freezed VDub and AVSMeter
Error:
Invoke not fully implemented, tried to call: BilinearResize but I will pretend it doesn't exist
Avisynth Error: escaped IScriptEnvironment::NotFound exceptions are non-recoverable, crashing...
MipSmooth(c1:clip; spatial:int:opt; temporal:int:opt; spatial_chroma:int:opt; temporal_chroma:int:opt; scenechange:float:opt; method:data:opt; downsizer:data:opt;
upsizer:data:opt; scalefactor:float:opt; weigh:int:opt; preset:data:opt; storecustom:int:opt; show:int:opt;)



*** The following 3 plugins only work with YUY2, and they all silently crashed VDub. I had to quickly take a screen grab of VSMeter in order to get the error message before it crashed.

DePulse (http://www5e.biglobe.ne.jp/~hoe/dv-and-movie/tipsxxx/index.html)
fGBlur (http://sky.geocities.jp/apechironnup/) - Part of the fPMD plugin.
GuavaComb (http://avisynth.org.ru/docs/english/externalfilters/guavacomb.htm) - If there's ever a fix, it also needs to be added to the prefetch list.

Error:
Invalid plane stride requested
Exception KeyError: KeyError<5376,> in <module 'threading' from 'C:\\Python33\\Lib\\threading.py'> ignored
DePulse(c1:clip; h:int:opt; l:int:opt; d:int:opt; debug:int:opt;)
fGBlur(c1:clip; sigma:float:opt;)
GuavaComb(c1:clip; Mode:data:opt; Recall:int:opt; MaxVariation:int:opt; Activation:int:opt;)




*** I couldn't get the following plugin it to work. I tried writing the parameters every way possible is VS but no luck.
I'm guessing it's because of duplicate parameter names? :)

cc (http://www.chiyoclone.net/details.html#cc)

cc(c1:clip; y1:int:opt; y2:int:opt; c1:int:opt; c2:int:opt; interlaced:int:opt; yc:float:opt; ylimit:int:opt; climit:int:opt;)



I still have a lot more plugins to test. I will then (hopefully) make a comprehensive list of all working AVISynth plugins.

One thing I'm still wondering, what are some of the benefits of adding plugins to the prefetch list?
Also, could you please explain a little about the different prefetch schemes?

#define OTHER(fname) if (name == #fname) return PrefetchInfo(1, 1, 0, 0);
#define SOURCE(fname) if (name == #fname) return PrefetchInfo(1, 1, 0, 0);
#define PREFETCHR0(fname) if (name == #fname) return PrefetchInfo(1, 1, 0, 0);
#define PREFETCHR1(fname) if (name == #fname) return PrefetchInfo(1, 1, -1, 1);
#define PREFETCHR2(fname) if (name == #fname) return PrefetchInfo(1, 1, -2, 2);
#define PREFETCHR3(fname) if (name == #fname) return PrefetchInfo(1, 1, -3, 3);
#define PREFETCH(fname, div, mul, from, to) if (name == #fname) return PrefetchInfo(div, mul, from, to);

[Myrsloik]

The OTHER and SOURCE macros don't really do anything. They're just for show and a reminder to myself about which functions I've actually checked. The PREFETCHX ones are the radius around the current frame that needs to be prefetched. For example PREFETCH0 means that a filter needs frame n as input to output frame n. PREFETCH1 means that n-1, n, n+1 are needed as input for frame n. You get the point.

The general PREFETCH macro allows you to divide and multiply the output frame number before determining which input frames are needed. So filters like decimate can be made to work.

The main reason for the prefetch stuff is that it makes implementing threading for avisynth filters a lot easier. With prefetching all frames a filter will need as input to produce a single frame will be available from the start.
If they're not available the filter will, like in single threaded avisynth, have to call the filter above it in the chain and wait for it to return. This also means that the filter instance can't be used by another thread either since avisynth filters are all single threaded. So then the other threads most likely have to sit around and wait and do nothing.

Note that avisynth-mt gets around this by spawning a lot of filter instances instead.

I hope this is clear enough.

[06_taro]

Myrsloik, could you please add "AviSynth function name: " before those prefetch and invoke warnings, so that it would be much easier to figure out which filter is not working as expected.

[Adub]

Myrsloik, kind of different question, but I figure you would know.

How often in video processing is there a operation dependence between planes? For example, is there a time when a filter needs information from the chroma planes to perform an operation on the luma plane?

The reason I ask is that I am considering adding stream support to my CUDA port. It might be incorporated into a later version, but it has some strong capabilities. Streams are a CUDA-ism that let the developer run multiple kernels in parallel on a CUDA device. This would allow for the ability to operate on all luma and chroma planes in parallel.

The only time I can think of an inter-plane dependence is possibly when performing motion compensation, so I thought I'd ask.

Simple filters like invert would see a nice speed boost, as they would likely only take as long as the luma plane to process, considering that there is much less data in the chroma planes (in subsampled video, that is).

[Myrsloik]

If you look at tbe existing avisynth fjlters it's actually quite rare. As you said motion estimation (with chroma included), ivtc and deinterlacing are the kinds that most often build a mask based on all planes and then applies it to each plane.
Even a simple filter like tweak or histogram needs it. If I have to pull a number out of my... hat I'd say about 20% of all filters need it.

[Adub]

Okay, thanks for your response, Myrsloik.

Luckily, stream-enabled kernels are optional, as CUDA issues all work to the default (0) stream anyways. I'll look at the simplest way of adding it to the core so that filter developers can use it if they want and ignore it if they don't.

It's likely just going to be some standard getCUDAStream() procedure with a pre-allocated pool of streams.

The pre-allocation is useful because I ran some tests with stream generation per frame kernel and there is enough startup overhead that it negates the parallel processing. Plus, only working with 3-32 streams is much easier to debug and profile (especially profile) than something like 2880 streams (damn near hangs NVidia's Visual Profiler).

[paradoxical]

There are other contributors to it, though, through work on core and by porting filters. It's mostly Myrsloik on the core since he knows the code the best. If you want there to be more developers, then help out.

I've been thinking of doing some work, but most of my time is spent working on my main project, bdsup2sub++, so I don't have as much free time ATM for other stuff. Once I get a new major release done for that, I'd love to see what I can pick off of Myrsloik's TODO list.

[Myrsloik]

Why aren't there any other developers besides the author?

Because the rest of the world can't see how great I am!

...or something.

[Mystery Keeper]

Personally I haven't given VapourSynth a shot yet because I couldn't install it. It wouldn't see my properly installed Python 3.

[LoRd_MuldeR]

Personally I haven't given VapourSynth a shot yet because I couldn't install it. It wouldn't see my properly installed Python 3.

I think it would be nice if the installer would give some more info, e.g. offer to download Python 3 now, instead of just aborting with a harsh error message.

Also: Wouldn't it be possible to bundle the required version of Python with Vapoursynth and create a "private" Python installation instead of messing with the "global" one?

[Myrsloik]

I think it would be nice if the installer would give some more info, e.g. offer to download Python 3, instead of just aborting with a harsh error message.

Also: Wouldn't it be possible to bundle the required version of Python with Vapoursynth and create a "private" Python installation instead of messing with the "global" one?

Python is fairly global by design. I really don't want to poke around and integrate it. The installation instructions clearly mention it as well.

[LoRd_MuldeR]

Well, I'm working on an application that makes use of Python too. I simply bundle the Python DLL and deploy it to the same folder where my "main" EXE file is located. The Python "lib" directory with all the .PY files can be compressed into a single ZIP file and put in to the same folder where the Python DLL is located. Python will look for it at the same name as the Python.DLL, only the .DLL extension replaced with a .ZIP extension. Finally, the Python modules we have to deliver as DLL (PYD) files need to be deployed as individual files. I just deploy them into a sub-folder inside my application's install folder and set the correct path at runtime, when I initialize the Python interpreter. So it's all very doable, if you want it. Just an idea though...

[Myrsloik]

Well, I'm working on an application that makes use of Python too. I simply bundle the Python DLL and deploy it to the same folder where my "main" EXE file is located. The Python "lib" directory with all the .PY files can be compressed into a single ZIP file and put in to the same folder where the Python DLL is located. Python will look for it at the same name as the Python.DLL, only the .DLL extension replaced with a .ZIP extension. Finally, the Python modules we have to deliver as DLL (PYD) files need to be deployed as individual files. I just deploy them into a sub-folder inside my application's install folder and set the correct path at runtime, when I initialize the Python interpreter. So it's all very doable, if you want it. Just an idea though...

I don't initialize the python interpreter in all cases. The vision is to make it work just like any other module and with the ability to export raw frame data to other python modules, such as numpy/whatever. I see no real reason to create a big bundle. I'm much more likely to integrate the pismo mount stuff in the installer actually.

[Mystery Keeper]

Problem fixed. Installator wouldn't find my Python because it was x64. Reinstalled x32, and it installed alright.

[Adub]

Myrsloik, I have a design question for you.

I'm at the point where I have a pretty stable CUDA implementation in the core, as well as a helper plugin for shipping frames back and forth on the GPU.

At this point, I'd like to start porting over the simplefilters that actually do processing in GetFrame() (Lut/Lut2/Transpose, etc). However, I'm a little unsure as to the best away to do this, as CUDA code is generally encapsulated in a separate ".cu" file, which would separate it from the current static nature of the simplefilters.c.

I did think about creating a separate plugin that is CUDA only, but that would be a crap ton of code duplication for all of the other functions (Create,Init,Free) for each filter in simplefilters.

I wanted to get your input on this before I start banging anything out.

For reference, I've been adding some work to the core, and wrapping anything that is CUDA/GPU specific in a "#if FEATURE_CUDA" block if it is in the .h or .cpp file. All other functionality is added to the new "vscore.cu" file.

Edit: Thinking about this further, if there was a way I could force Waf to only use NVCC to compile simplefilters.c instead of gcc, I could write the code directly into simplefilters.c I think using preprocessor checks.

[Adub]

Myrsloik, I have a design question for you.

I'm at the point where I have a pretty stable CUDA implementation in the core, as well as a helper plugin for shipping frames back and forth on the GPU.

At this point, I'd like to start porting over the simplefilters that actually do processing in GetFrame() (Lut/Lut2/Transpose, etc). However, I'm a little unsure as to the best away to do this, as CUDA code is generally encapsulated in a separate ".cu" file, which would separate it from the current static nature of the simplefilters.c.

I did think about creating a separate plugin that is CUDA only, but that would be a crap ton of code duplication for all of the other functions (Create,Init,Free) for each filter in simplefilters.

I wanted to get your input on this before I start banging anything out.

For reference, I've been adding some work to the core, and wrapping anything that is CUDA/GPU specific in a "#if FEATURE_CUDA" block if it is in the .h or .cpp file. All other functionality is added to the new "vscore.cu" file.

Edit: Thinking about this further, if there was a way I could force Waf to only use NVCC to compile simplefilters.c instead of gcc, I could write the code directly into simplefilters.c I think using preprocessor checks.

Okay, I think i've figured out a way I can do this. Essentially, I'll create a simpefilters.cu file that holds all of the GPU kernels and any associated wrappers that are necessary for calling them. Then, in simplefilters.c, I'll implement a small #if-surrounded block that will allow for the use of these new kernels if Vapoursynth is compiled with CUDA support.

I think I can even get it so that we can have the GPU and CPU filtering capabilities live side-by-side, and just filter the frame based off of it's FrameLocation. That way there is little extra work that needs to be done by the user.

Edit: Er, didn't mean to make a new post, don't know how that happened.

[Selur]

btw. the starter script over at http://www.vapoursynth.com/doc/gettingstarted.html
import vapoursynth as vs
# needed for stdout
import sys
# create a core instance
core = vs.Core()
# load a native vapoursynth plugin
# you should use absolute paths as the working directory may not be what you think it is
core.std.LoadPlugin(path=r'c:\plugins\ffms2.dll')
# load an avisynth plugin
# the loaded functions will always end up in the avs namespace
core.avs.LoadPlugin(path=r'c:\avisynth\UnDot.dll')
# open a video file; ret is now a clip object
ret = core.ffms2.Source(source='Super Size Me.avi')
# apply the undot filter to the video
ret = core.avs.UnDot(clip=ret)
# output the clip to stdout with y4m headers (useful for x264 encoding/mplayer playback)
ret.output(sys.stdout, y4m=True)
has to mistakes:

ret = core.ffms2.Source(source='Super Size Me.avi') need to be:
ret = core.ffms2.Source(source=r'Super Size Me.avi')
ret = core.avs.UnDot(clip=ret) needs to be:
ret = core.avs.UnDot(ret)

if the intention of the page is not to scare away users it might be a good idea to fix this. :D

Cu Selur

[jackoneill]

btw. the starter script over at http://www.vapoursynth.com/doc/gettingstarted.html

has to mistakes:

ret = core.ffms2.Source(source='Super Size Me.avi') need to be:
ret = core.ffms2.Source(source=r'Super Size Me.avi')
ret = core.avs.UnDot(clip=ret) needs to be:
ret = core.avs.UnDot(ret)

if the intention of the page is not to scare away users it might be a good idea to fix this. :D

Cu Selur
I'm not sure about the second one, but the first one is not a mistake. You don't /have to/ use raw strings. It's just more convenient when you have backslashes in your paths (like in Windows).

[Chikuzen]

#!/usr/bin/env python3

import vapoursynth as vs
import sys

core = vs.Core()
std = core.std

def ivtc(clip, offsets, cycle=10, tff=True):
clip = std.SeparateFields(clip, tff)
clip = std.DoubleWeave(clip, tff)
return std.SelectEvery(clip, cycle, offsets)

def show_progress(c, t):
print('%i / %i' % (c, t), end='\r', file=sys.stderr, flush=True)

src = std.BlankClip(width=1920, height=1080, format=vs.YUV420P8, length=50000)

clips = []
for f in range(200):
clips.append(ivtc(src[f * 100: f * 100 + 30], [1, 4, 6, 9]))
clips.append(ivtc(src[f * 100 + 30: f * 100 + 60], [0, 2, 5, 7]))
clips.append(ivtc(src[f * 100 + 60: f * 100 + 100], [1, 3, 6, 8]))

last = std.Splice(clips)
#print(last, file=sys.stderr)
last.output(sys.stdout, False, 0, show_progress)


When I ran this script, the speed falls at about 6000th frame and the amount of the memory used continued increasing.
https://dl.dropbox.com/u/19797864/isthismemleak.jpg
Is this bug or limitation ?

[Adub]

I can confirm this behaviour on Ubuntu 12.04, 64-bit, Python version 3.2.3.

The speed definitely slows down, but I'm not sure if it's a constant decrease. However, my memory usage did spike as high as 3.2GB.

[Reel.Deel]

I couldn't help myself, I ran Chikuzen's script using VFW and got similar results.
I also used AVSMeter to get a nice log with CPU usage and speed. Unfortunately it crashed when the memory got around 1650mb.
Regardless, here's the log (https://www.dropbox.com/s/jrua9wo6ir616oe/VS%20Test.log).

[Myrsloik]

I think I know at least half the issue. There is a missing free of the underlying frame data reported by ADub that's fixed in svn. I think that's what causes you to run out of memory after thousands of frames. There may be another issue with the cache strategy as I haven't tested it on bigger/complicated scripts. Guess I'll prepare a new test version later today so you can see if it really did get fixed.

[Adub]

Actually Myrsloik, my confirmation two posts above was with the latest SVN changes (rev 442 last time I checked). I'm not quite sure where the leak is at this point.

[gnaggnoyil]

Is there anyway to "fade", or to "dissolve" some frames of a clip in vapoursynth? In avisynth I can use the "fade" and the "dissolve" function. Is it able to do so in vapoursynth? I can't find any documents about it in the offical website, nor can I find it in doom9 :(

[jackoneill]

Is there anyway to "fade", or to "dissolve" some frames of a clip in vapoursynth? In avisynth I can use the "fade" and the "dissolve" function. Is it able to do so in vapoursynth? I can't find any documents about it in the offical website, nor can I find it in doom9 :(

Assuming "fade" in avisynth does what I think it does:

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)


Tweak the colour of the blank clip to change the colour it fades to/from.
Tweak the parameters of range() to make it fade /in/, rather than out (make it count backwards).
Replace blank with some other clip, say fade_input2[i], to make it fade from one scene to another.

~~~~~

I don't know what "dissolve" should look like.

[gnaggnoyil]

thanks a lot :) it does helps. I didn't know that videoNode[i] returns a one-frame clip including the i-th frame of videoNode before, now I got it :) Really much more powerful than avisynth.

[digitall.h]

Hi @all,
is it happening further development of Vapoursynth in the background?.
I read in Vapoursynth project page that Myrsloik had a new job (sort of?) and development would slow down. That was published in the beginning of March. Was just Myrsloik developing Vapoursynth?.

It would be sad, since this project looks really promising, specially for those of us living in the Linux world, and missing avisynth natively.

I wish I could be of a help, but I'm in the "Hello world!" phase of Python...:(
I just can help testing.

[Myrsloik]

I've only written a few more lines of code since the last post. It's not dead but I spend all day programming other things... for money. It's actually not that much more code needed to make the core part complete so it'll definitely happen some day.

Also, real life takes time.

[digitall.h]

I've only written a few more lines of code since the last post. It's not dead but I spend all day programming other things... for money. It's actually not that much more code needed to make the core part complete so it'll definitely happen some day.
Great!, it's good to know this.

Also, real life takes time.
Of course.
I really admire, respect and thank the time programmers like you and many others in this site spend creating projects and sharing them with everybody.

:)

[Adub]

@digitall.h
Is there something missing from Vapoursynth that you'd like to see? I ask because you speak of the project being promising, which just sounds to me personally like it's missing something you want.

And I'm totally with you on the Linux support. I do all of my Vapoursynth development and usage on Linux.

[kolak]

Yes:
-native QTGMC or at least yadifmod
-better "support" for interlaced video
-better source filters (ffms2, avisource still have problems)
-8bit+ support for core filters- like deinterlacing, etc
-frame prefetching support for avs filters
-many more

Example of great vapoursynth filter implementation is fmtconv from Cretindesalpes.

[sl1pkn07]

in my knowledge: (a mode of information)

cross plataform plugins:

convo2d
d2vsource
ffms2
fmtconv
genericfilters
histogram
lsmashsource
nnedi3
scenechange
scxvid
temporalsoften
vsimagereader
vsrawsource

windows plugins:

VS_AvsReader (work with avisynth plugins)
vscolormatrix (?) (don't build on my linux)

mixed plugins (use avisynth plugins to work)

havsfunc

[Adub]

I suppose I should have been a bit more clear, as I ment develop to the actual Vapoursynth project.

Almost everything that you have listed can be done in a plugin or script format for Vapoursynth's use, which can be done by any willing developer, not just Myrsloik.

The biggest hurdle for QTGMC at this point is the MC part. I know that Myrsloik wanted to look into a new version of MVTools for Vapoursynth, but that is a large task.

Currently all of the core filters support 8/9/10/16 bit video (with some even supporting float). But I agree, lack of a proper deinterlacer is a bit of a problem.

As for the "better source filters", what problems do you have with FFMS2? I've used it in numerous tests before and I've had no problems.

[kolak]

Except fmtconv and some source filters I don't think anything else supports 8bit+.

Avisource has speed problem (not a big deal for now), ffms2- well it sort of works, but far from being reliable. There is no official build, some random builds etc. I think vapoursynth needs reliable and well written source filter, as without it rest of the engine can't be used properly.

I know Myrsloik is busy, which is shame, but he needs real life and money :)