Vapoursynth

[jackoneill]

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

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]

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

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

[06_taro]

Myrsloik, I met some strange results from Lut and Expr for YUV420P16.

I used a simple script to reproduce it:

PHP Code:

import vapoursynth as vs
core = vs.Core()
std  = core.std
avs  = core.avs
avs.LoadPlugin('DGDecodeNV.dll')
dgi  = 'test.dgi'
clip = avs.DGSource(dgi)
clip = core.fmtc.bitdepth(clip, bits=16)

lut = []
for x in range(2**clip.format.bits_per_sample):
    lut.append( x )

res = std.Lut(clip, lut, [0, 1, 2]) 


or I changed the last line to:

PHP Code:

res = std.Expr( clip, 'x' ) 


It is expected that Lut / Expr should return exactly the original value of pixel, and is same as clip. However, with Lut, I got a nearly blank (0, 0, 0) msb, and few information in lsb related to the original clip; while with Expr, the whole picture turned pink, and looked as if it was the input clip horizontally interleaved a full (65535, 65535, 65535) clip.

Some other filters which support YUV420P16 like generic.Blur gives expected results, so I suppose something went wrong in Lut and Expr, or in my script. Naturally, Expr(clip, '') works as it should, so does specifying planes[] to preserve data in certain planes. Using a const in expression like lut.append(32768) or Expr(clip, '32768') also works well. Did I make any mistakes, or do these two functions need special workaround like re-order bytes, or is there any regression in the filters?

Env:
Win Server 2012 Datacenter (x64)
python 3.3 win32
vapoursynth r18
Any video, any source filter, any resizer for 8->16 conversion, and any other pre-filters, as long as the input clip for Lut/Expr is YUV420P16.
Viewed by vfw dithered by fmtc.bitdepth, or encoded by FFmpeg/x264 with y4m or raw with specified format/input-depth/csp, or raw yuv generated by clip.output() function.

Didn't test other csps, as I'm still using masktools for 8-bit stuffs :P

[Adub]

Hmm, good spot, 06_taro.

Just looking at the code, with no testing done what so ever, it may be due to the fact that the srcp pointer is not being cast to uint16_t when being read in LUT.

Ex:

((uint16_t *)dstp)[x] =  lut[srcp[x]];

should be

((uint16_t *)dstp)[x] =  lut[((const uint16_t *)srcp)[x]];

As for Expr, the C-code looks fine, but the plugin normally runs with the ASM code, which I don't read well/at all. I assume something similar may be happening.

It might be good to add a regression test in the Python tests, just for good maintenance sake. Hell, I can write one when I get home.

Edit: Looks like the same issue exists in LUT2:

((uint16_t *)dstp)[x] = lut[(srcpy[x] << shift) + srcpx[x]];

[Adub]

Here's a patch to simplefilters.c which should fix LUT and LUT2

diff --git a/src/core/simplefilters.c b/src/core/simplefilters.c
index 9ea2a97..738c337 100644
--- a/src/core/simplefilters.c
+++ b/src/core/simplefilters.c
@@ -1885,7 +1885,7 @@ static const VSFrameRef *VS_CC lutGetframe(int n, int activationReason, void **i

                     for (hl = 0; hl < h; hl++) {
                         for (x = 0; x < w; x++)
-                            ((uint16_t *)dstp)[x] =  lut[srcp[x]];
+                            ((uint16_t *)dstp)[x] =  lut[((uint16_t *)srcp)[x]];

                         dstp += dst_stride;
                         srcp += src_stride;
@@ -2052,7 +2052,7 @@ static const VSFrameRef *VS_CC lut2Getframe(int n, int activationReason, void **

                     for (hl = 0; hl < h; hl++) {
                         for (x = 0; x < w; x++)
-                            ((uint16_t *)dstp)[x] =  lut[(srcpy[x] << shift) + srcpx[x]];
+                            ((uint16_t *)dstp)[x] =  lut[(((uint16_t *)srcpy)[x] << shift) + ((uint16_t *)srcpx)[x]];

                         dstp += dst_stride;
                         srcpx += src_stride;

And a new regression test framework under test/test_regression.py

import unittest
import vapoursynth as vs

class RegressionTestSequence(unittest.TestCase):

    def setUp(self):
        self.core = vs.Core()

    def checkDifference(self, cpu, gpu):
        diff = self.core.std.PlaneDifference([cpu, gpu], 0, prop="PlaneDifference0")
        diff = self.core.std.PlaneDifference([diff, gpu], 1, prop="PlaneDifference1")
        diff = self.core.std.PlaneDifference([diff, gpu], 2, prop="PlaneDifference2")

        for i in range(diff.num_frames):
            frame = diff.get_frame(i)
            self.assertEqual(frame.props.PlaneDifference0[0], 0)
            self.assertEqual(frame.props.PlaneDifference1[0], 0)
            self.assertEqual(frame.props.PlaneDifference2[0], 0)

    def testLUT16Bit(self):
        clip = self.core.std.BlankClip(format=vs.YUV420P16, color=[69, 242, 115])

        lut = []
        for x in range(2 ** clip.format.bits_per_sample):
            lut.append(x)

        ret = self.core.std.Lut(clip, lut, [0, 1, 2])

        self.checkDifference(clip, ret)

if __name__ == '__main__':
    unittest.main()

[sl1pkn07]

one little fix

https://code.google.com/p/vapoursynth/source/browse/trunk/include/VSScript.h#21

is "#include VapourSynth.h" (#include "vapoursynth.h" fail build in linux (case sensitive))

[Selur]

Here's what I tried to get Vapoursynth working in my Linux Mint 64bit 13.04 (inside a Virtualbox) working:

1. Installing a bunch of dependencies.

sudo apt-get install build-essential libqtcore4 python3 python3-dev wget subversion yasm libswscale-dev libavcodec-dev libass-dev autoconf libavformat-dev mplayer

2. Extracting and installing Cython (http://pypi.python.org/packages/sour...ython-0.19.zip):

sudo python3 setup.py install

3. Checkout, build and install Vapoursynth:
3.1 checkout
[code]svn checkout http://vapoursynth.googlecode.com/svn/trunk vapoursynth
cd vapoursynth
3.2 fixing typo in include/VSScript.h:

#include "vapoursynth.h"

to

#include "VapourSynth.h"

3.3 installing

./bootstrap.py && ./waf configure && ./waf build && sudo ./waf install
sudo ./setup.py install
sudo ldconfig

4. checking out, extracting and building latest libav (https://libav.org/releases/libav-9.5.tar.gz), since Ubuntu 13.04 is missing libavresample
5. checking out and building ffms2

svn checkout http://ffmpegsource.googlecode.com/svn/trunk ffms2
cd ffms2
./autogen.sh
./configure --enable-shared
make

5. creating an example script named vstestscrpt.vpy:

#!/usr/bin/python3
import vapoursynth as vs
import sys
core = vs.Core()
core.std.LoadPlugin("/usr/local/lib/libffms2.so")
ret = core.ffms2.Source("/home/selur/Desktop/test.avi")
ret.output(sys.stdout, y4m=True)

6. making the script excecuteable

chmod +x vstestscrpt.vpy

7. calling mplayer to test the whole thing:

$ ./vstestscript.vpy  | mplayer

Problem is the last step gives me:

Traceback (most recent call last):
File "./vstestscript.vpy", line 7, in <module>
ret.output(sys.stdout, y4m=True)
File "vapoursynth.pyx", line 676, in vapoursynth.VideoNode.output (build/src/cython/vapoursynth.c:10747)
vapoursynth.Error: 'write() call returned error'

-> Does anyone have an idea what is doing wrong? (or is this a bug?)

Cu Selur

[sneaker_ger]

Is mplayer set to y4m input via pipe? Because that's what you've set your VapourSynth output to.

[Selur]

doh, I was missing a '-', needs to be 'mplayer -'

[sl1pkn07]

for Archlinux users: https://aur.archlinux.org/packages/?O=0&K=vapoursynth

one little question, cpython is dependency for run or only for build?

greetings

[gnaggnoyil]

can i use avisynth runtime functions in a vapoursynth script? i.e., can i let core.avs.IsCombedTIVTC() work in vapoursynth, either using it in core.std.SelectClip(), or just return a boolean list, or do anything else?
if can't, what else could be used to replace IsCombedTIVTC for above usage?

[Adub]

@Selur,

Just a heads up, Mplayer/MPV might prefer that you disable the "y4m" setting on output, as setting it to true outputs an extended Y4M format that requires specific support by the reader, such as X264. Setting y4m=False still outputs standard y4m, and should be quite compatible with any command line player.