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]

Originally Posted by LoRd_MuldeR

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]

Originally Posted by Myrsloik

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.

Originally Posted by Myrsloik

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.

Originally Posted by Myrsloik

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...ng-conventions)?

[Myrsloik]

Originally Posted by 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...ng-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]

Originally Posted by Myrsloik

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]

Originally Posted by LoRd_MuldeR

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]

Originally Posted by 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.

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 to see if the warning would be displayed.

Here's a list of plugins that need to be added to the prefetch list.

• checkmate
• DeCrawl
• DeCross
• DeDot
• DeGrainMedian
• dw3DNR
• FluxSmooth
• frfun7
• NoMoSmooth
• PNLM
• SVPFlow
• TempLinearApproximate
• TTempSmooth

PHP Code:

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
• TComb

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...

PHP Code:

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
  * 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...

PHP Code:

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
• fGBlur - Part of the fPMD plugin.
• GuavaComb - 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

PHP Code:

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

PHP Code:

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).