Vapoursynth

[Myrsloik]

Website:
http://www.vapoursynth.com/
VapourSynth ChangeLog (https://github.com/vapoursynth/vapoursynth/blob/master/ChangeLog)
Documentation (http://www.vapoursynth.com/doc/)
List of all known plugins and scripts (http://www.vapoursynth.com/doc/pluginlist.html)
VapourSynth Editor (https://bitbucket.org/mystery_keeper/vapoursynth-editor/downloads)

[TheProfileth]

Just thought I would post the link here
http://www.vapoursynth.com
Apparently it is out and you can even install it, albeit with a python command line
http://www.vapoursynth.com/installation-instructions
Apparently you can use current avisynth plugins in it though I doubt all of them work correctly it is very interesting.
import vapoursynth
core = vapoursynth.VSCore()
core.avisynth.LoadPlugin(path='ffms2.dll')
core.avisynth.LoadPlugin(path='sangnom.dll')
a = core.avisynth.FFVideoSource (path='clouds.avi')
b = core.avisynth.SangNom (c1=a)
b.output(sys.stdout, y4m=1)
So can someone tell me exactly what this means though? Since I have just now heard of this?

[JEEB]

Apparently it is out and you can even install it, albeit with a python command line
It's still in a (relatively) closed circle testing phase, but the site is being pushed up and working. As you can see, the binary links aren't there yet, for example.

So can someone tell me exactly what this means though? Since I have just now heard of this?It means that there will soon be a (cross-platform) thing with a C API that you can plug into a scripting language of your choice (the default bindings are for Python 3.x). It also has a simplistic Avisynth plugin loading mode for Windows that should let you use most plugins as-is (MVTools and DirectShowSource seem to be some of the exceptions at the moment, but myrs is working on it).

Bottom line: Someone got some free time, and had been boiling ideas from quite a few months ago. Now they are becoming "a thing".

[TheFluff]

It's designed as a video filtering framework (sort of like Avisynth) but unlike Avisynth it:

isn't from the 90's
supports native frame-based multi-threading
is extensible (supports arbitrary per-frame metadata; new colorspaces can be defined at runtime, etc)
is cross-platform
ships with Python 3 bindings; no support for a home-grown scripting language is planned
has a C API rather than a C++ API, so it's actually portable
has native support for things like clips with changing dimensions and other properties, as well as clips with infinite duration


As JEEB said it also has an Avisynth compatibility layer that emulates the Avisynth 2.5 plugin interface; loading Avisynth plugins does not require Avisynth itself. Not all plugins are supported yet.

Doing something like this has been discussed for ages in the usual complaining-about-Avisynth circles, but now Myrsloik finally went and did it.

This is change. This is the future. This is vapour we can breathe in.
GET HYPE

[TheProfileth]

Will there be native support for higher bitdepths?

[TheFluff]

Will there be native support for higher bitdepths?

As I said, new colorspaces can be defined at runtime, so yes, there is "native support" for everything you can think up definitions for. Plugins can be written to support runtime-defined colorspaces too, since the definitions can be read programmatically.

[jmac698]

This is what I've been waiting for.

[mastrboy]

Will it be open source when released?

[TheFluff]

Will it be open source when released?

yes

edit: for the vapourware lovers, it should be noted that this thing actually exists and works already, unlike, say, avisynth 3

[Reel.Deel]

I'm assuming Vapoursynth will be in 64-bit, correct? Also, its very nice to hear that it's compatible with Avisynth plugins. Since the scripting language it's different, It's obvious Avisynth scripts won't be compatible, right?
Unless I'm missing something.

[TheFluff]

It can be built as either 32- or 64-bit, yes. No, you can't run Avisynth scripts (at least not right now); only the API is emulated, not the script parser.

[mastrboy]

What about the inbuilt avisynth functions? Are there Vapoursynth functions built-in for the stuff like: ApplyRange, SelectEven/Odd, Trim, SeparateFields... etc.
Or maybe (probably a really bad idea), a possibility to load avisynth.dll in vapoursynth?

[JEEB]

What about the inbuilt avisynth functions? Are there Vapoursynth functions built-in for the stuff like: ApplyRange, SelectEven/Odd, Trim, SeparateFields... etc.
Or maybe (probably a really bad idea), a possibility to load avisynth.dll in vapoursynth?
Yes, operations commonly used in Avisynth have already been implemented in VapourSynth. I see "SelectEvery", "Trim" and "SeparateFields" already implemented of those you mention, and quite a few others.

[clsid]

Are there any plans for a DirectShow filter that can serve as a replacement for ffdshow's AviSynth processing?

[TheFluff]

SelectEven/SelectOdd are special cases of SelectEvery and are not going to be implemented (you can of course "implement" them trivially in Python if you want). Similarly, ApplyRange is a special case of Trim (plus splicing) and can be trivially implemented in Python as well. Vapoursynth will not have an 1:1 copy of all Avisynth functions, especially not since the scripting language is now a real programming language so implementing interesting script functions is mostly trivial.

Avisynth has a ton of old crufty functions that are in the "core" for very unclear reasons, anyway. Why are there five different level manipulation functions (coloryuv, levels, limiter, rgbadjust, tweak) with a ton of overlapping functionality? Why are things like PeculiarBlend, FixBrokenChromaUpsampling and FixLuminance core functions? Why does CropBottom exist? Why does the basic "fade" function (equivalent to dissolve+blankclip) need nine different function names and prototypes? God (or maybe BenRG) alone knows.


Are there any plans for a DirectShow filter that can serve as a replacement for ffdshow's AviSynth processing?
Not at this time. It'd be pretty easy to implement for someone who is familiar with dshow though (and that's usually the bottleneck for dshow-related stuff anyway).

[mastrboy]

Good point, i only see 2 arguments that can be made for those functions,
One being It's easier to get into the script language with such "alias" functions if your not well versed in scripting, and the second one that there might be various optimizations behind the function call, like there is for mt_masktools. Like mt_average is just mt_lutxy("x y + 2 /") but faster.

[The_Paya]

I still remember me thinking "wish this was python" the first time I got to play with Avisynth.

Just Awesome.

:thanks:

For directshow sources and whatnot, here's an example of what you can do with python: https://gist.github.com/3549096
And that's just (the graph building) part of a python program I wrote to watch tv with my capture card, forcing the ffdshow filters in the graph.

[mandarinka]

I still remember me thinking "wish this was python" the first time I got to play with Avisynth.

Just Awesome.


Well, for the majority of people who know nothing about programming, avisynth not being a "proper programming language" and having all sorts of aliases like selectodd (plus dumb simple syntax) is actually much better.

I got a feeling that from the usability PoV, to us simple monkeys the glorious python thingy is going to be about as attractive as the USF subtitle format (http://blog.aegisub.org/2008/07/universal-subtitle-format-post-mortem.html) was, compared to ASS/SSA.

But who knows, maybe I just don't get it and/or hate any change.

[JEEB]

I got a feeling that from the usability PoV, to us simple monkeys the glorious python thingy is going to be about as attractive as the USF subtitle format (http://blog.aegisub.org/2008/07/universal-subtitle-format-post-mortem.html) was, compared to ASS/SSA.

You do understand that no-one actually really implemented USF writing, right? And that it really wasn't better in any real sense? It was bound to fail. Also, you just compared a scripting language with XML. IDon'tEven.

I do agree, though, that this most certainly will be less simple for "simple monkeys" until someone writes VapourSynth bindings for something more "monkey"-compatible. Or hell, someone could write a python thingy to make usage of the default VapourSynth bindings less verbose etc. The difference here is that VSynth core is really a thing, the rest is up to the people. And for those who aren't opposed to some Python, they can just use the pre-built bindings.

[TheFluff]

Monkeys have no business writing scripts any more complicated than filter().filter().filter() and that will be just as easy in python as it is in avisynth, so I don't really see your point.

[StainlessS]

If you sit a monkey at a keyboard for long enough, it would eventually compose the complete
works of TheFluff. :)

[mandarinka]

Well, I didn't mean to criticise you at all. It was actually my point that monkey (me) is fine with filter().filter().filter().

I just wanted to chill the enthusiasm a bit, because it seems to me that many people are considering this to be the "next big thing" while in fact it is a "next big thing *for function writers*"...

Users (the dudes filtering video) on the other hand generally just use linear filter chains and writing that in the python syntax is not going to be a good idea (at least it will be a lot of tiresome redundant typing).
They better not expect to be benefiting from it, else they will be disappointed. Of course, once somebody writes that avisynth script interpreter/parser, then they can use vapoursynth as backend without thinking about it (but somebody will have to write that).

[Reel.Deel]

It can be built as either 32- or 64-bit, yes. No, you can't run Avisynth scripts (at least not right now); only the API is emulated, not the script parser.

Cool. So this mean that to fully take advantage of the 64-bit perks, Avisynth plugins would have to ported to 64-bit or similar plugins would have to be developed... Right?

_____________

From a monkey's point of view, looking at some samples (http://webcache.googleusercontent.com/search?q=cache:AzWRysQG9JEJ:pastebin.com/GwtMwugn+VapourSynth&cd=4&hl=de&ct=clnk&gl=de) posted at pastebin. The scripting language doesn't *seem* that hard. But then again I'm just a monkey so I might be wrong.:p

[JEEB]

Cool. So this mean that to fully take advantage of the 64-bit perks, Avisynth plugins would have to ported to 64-bit or similar plugins would have to be developed... Right?
Yes, you would have to port stuff to make those things usable in native 64bit binary on Windows or natively on Linux (32bit/64bit). Myrsloik has shown interest in porting a plugin or two himself to native VapourSynth plugins, but in other cases people would have to work by themselves. Firesledge for example has been given access to the source code in order to both give comments and maybe port his dither package to VapourSynth :)

Also, to be honest I think that the fact that we lack something a la AvsP(mod) is more of a problem than the fact that you would have to write some more redundant stuff.

[Reel.Deel]

A 64-bit dither with a true high bit depth workflow sounds awesome. :)

So what would we use to view/render high bit depth video?

[gyth]

I just wanted to chill the enthusiasm a bit, because it seems to me that many people are considering this to be the "next big thing" while in fact it is a "next big thing *for function writers*"...
You don't have to be a function writer to use functions.

Easy access to OpenCL could give a speed boost to all the many things with pixel level parallelization.

Monkeys have no business writing scripts any more complicated than filter().filter().filter() and that will be just as easy in python as it is in avisynth, so I don't really see your point.
Can python add an implicit "last = last." to statements?

[Myrsloik]

Vapoursynth has been released. You can get it from http://www.vapoursynth.com
It is a kind of reimaging of avisynth but with python as the scripting language and many other improvements. It is still a bit incomplete and doesn't have the ability to open script files as regular video in applications... yet.

Many avisynth plugins can be loaded and used without doing anything special, this functionality is however limited to yv12 input and output. Some filters that do weird stuff simply do not work (examples of popular broken filters are mvtools2).

Report your success and failures with different avisynth filters, or the internal ones.

known issues:
absolute paths usually needed to load plugins
may deadlock with some avisynth plugins (set the number of threads, VSCore(threads=4))

r3:
fixes even more threading and performance issues
adds special support for yuy2 and rgb32 so most avisynth filters should work
added hacks to make mvtools2 work

r2:
fixes a large number of threading issues
removed the stupid clip.vi.width thing in python, now it's simply clip.width
fixed the frame reordering in the python bindings, now frames pop out in the expected order

r1:
buggy first version

[Reel.Deel]

That is a very nice surprise!! Thanks a lot for all your work. Best wishes to you and to Vapoursynth. :)


-----------------------------------------

EDIT:

For a complete python newb like me, do you mind posting an example of how to losslessly encode the output of vapoursynth.
I checked "Getting started" page but it's kinda vague.

[hajj_3]

nice, are there any speed improvements compared to avisynth so far? Maybe you could do a benchmark with a 720p x264 and 720x400 x264 and xvid with mpeg2 and h.264 sources. Does this use OpenCL acceleration yet? multithreading yet? 64bit yet?

[Myrsloik]

nice, are there any speed improvements compared to avisynth so far? Maybe you could do a benchmark with a 720p x264 and 720x400 x264 and xvid with mpeg2 and h.264 sources. Does this use OpenCL acceleration yet? multithreading yet? 64bit yet?

KNOWN ISSUES IN R1: I messed up the python bindings slightly so you may get frames out of order when you pipe stuff. TDecimate is also derp. You've been warned. R2 coming in 36h or so.

It does use frame level multithreading but I haven't done a lot of speed tests yet but it should scale fairly well though.

And a few words about 64bits. Good but not magic. You get most of the speed benefits in 32bit code by using sse2 instructions so the gap isn't huge. The second benefit with address space is something I hope to simply get around with better memory management. X64 will come but I think most people will value partial avisynth binary compatibility higher.

Gpu stuff is somewhere in the slightly distant future. I need a stable base first.

[Chikuzen]

>>> import vapoursynth as vs
>>> c = vs.Core()
>>> c.avs.LoadPlugin(path=r'C:\AviSynth\plugins_x86\rawsource26.dll')
>>> clip = c.avs.RawSource(file=r'D:\video\derf\soccer_4cif.y4m')
>>> print(clip.videoinfo.width)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'vapoursynth.VideoNode' object has no attribute 'videoinfo'
>>> print(clip.vi.width)
704


almost all users don't know the variable name of the struct VideoInfo defined by source filter plugin.
need function GetVideoInfo().

[naoan]

Well, I didn't mean to criticise you at all. It was actually my point that monkey (me) is fine with filter().filter().filter().

I just wanted to chill the enthusiasm a bit, because it seems to me that many people are considering this to be the "next big thing" while in fact it is a "next big thing *for function writers*"...

Users (the dudes filtering video) on the other hand generally just use linear filter chains and writing that in the python syntax is not going to be a good idea (at least it will be a lot of tiresome redundant typing).
They better not expect to be benefiting from it, else they will be disappointed. Of course, once somebody writes that avisynth script interpreter/parser, then they can use vapoursynth as backend without thinking about it (but somebody will have to write that).

How about getting cooler and better scripts from the developers because it's gotten easier to write and maintain script now?

I'd say that more power to the devs, the more power to end users too, no? :rolleyes:

[Myrsloik]

I've posted the second version now. It should be stable enough for general experimentation now.

[TheFluff]

For those who aren't feeling the hype, it might be worth mentioning that this release can multithread many Avisynth filter chains better than Avs-MT can.

[Myrsloik]

For those who accept numbers pulled out of dark body cavities, here are some examples from yesterday evening:
FFVideoSource().4xTnlMeans() (maybe not the most appealing filter chain)
VS: 35s
Avisynth: 130s

FFVideoSource().4xTFM() (I know, retarded)
VS: 30s
Avisynth: 50s

This was on a core i5 3570k. There are probably also a few more improvements that can be made to thraed scheduling/caching in later releases. There's also a vfw module coming some day in the not too distant future (open python scripts as video just like .avs files)

[mastrboy]

Is there a way to load vapoursynth scripts in virtualdub or avspmod for previewing? Currently i have only managed to output raw yv12 video data on the command line...

[Myrsloik]

Is there a way to load vapoursynth scripts in virtualdub or avspmod for previewing? Currently i have only managed to output raw yv12 video data on the command line...

No, not yet. The next release will most likely have some kind of support for it.

[TheFluff]

Is there a way to load vapoursynth scripts in virtualdub or avspmod for previewing? Currently i have only managed to output raw yv12 video data on the command line...

The VfW module Myrsloik is talking about will let you do that. Currently the only way is to pipe the output to x264 or some other compression tool that supports y4m input.

[Chikuzen]

I tried the following.

#!/bin/env python3
# vs_test1.py
import sys
import vapoursynth as vs
core = vs.Core()
core.avs.LoadPlugin("rawsource26.dll")
clip = core.avs.RawSource(file="soccer.y4m")
clip.output(sys.stdout, y4m=True)

> python vs_test.py > out.y4m

However, this script only outputted y4m header, and it did not work after it at all.

It seems that vapoursynth dislikes avisynth source filters other than ffms2 :(

[Myrsloik]

I tried the following.

#!/bin/env python3
# vs_test1.py
import sys
import vapoursynth as vs
core = vs.Core()
core.avs.LoadPlugin("rawsource26.dll")
clip = core.avs.RawSource(file="soccer.y4m")
clip.output(sys.stdout, y4m=True)

> python vs_test.py > out.y4m

However, this script only outputted y4m header, and it did not work after it at all.

It seems that vapoursynth dislikes avisynth source filters other than ffms2 :(
http://forum.doom9.org/showpost.php?p=1589319&postcount=142

Only avisynth 2.5 plugins supported.

[kolak]

Will it be possible to do something like virtual file system?

http://forum.doom9.org/showthread.php?t=133313

[active1]

thanx! i'll try it now :)
stupid question: what is the advantage of VapourSynth over Avisynth MT?

[Myrsloik]

Will it be possible to do something like virtual file system?

http://forum.doom9.org/showthread.php?t=133313

I suppose so. You could probably reuse quite a bit of the sourcecode so replacing avisynth as the backend should be quick. Or so my 15 second survey of the sourcecode tells me.

thanx! i'll try it now :)
stupid question: what is the advantage of VapourSynth over Avisynth MT?

VapourSynth may one day have all its threading issues fixed. I'm not so optimistic about avisynth mt...

And with that I return to my debugger.

[Rumbah]

The site seems to be down, is there another way to download it?

[sneaker_ger]

http://www.mediafire.com/?64s562ufwy8x7fp (Windows r2)

[Myrsloik]

The site seems to be down, is there another way to download it?

Not for the moment, no. I will make a third release once it's back up. I guess you get what you pay for... and I pay $1.78/month.

Anyway, have some performance comparisons from r3 while you wait:
Avisynth 2.5.8
$ time avs2yuv.exe test.avs - > NUL
test.avs: 640x368, 24000/1001 fps, 5000 frames

real 1m23.680s
user 0m0.000s
sys 0m0.015s

VapourSynth r3:
$ time /c/Python32/python.exe test.py > NUL

real 0m23.753s
user 0m0.015s
sys 0m0.000s
Script:

import vapoursynth as vs
import sys
core = vs.Core(threads=4)
core.avs.LoadPlugin(path='ffms2.dll')
core.avs.LoadPlugin(path='mvtools2.dll')
ret = core.avs.FFVideoSource(source='possible rule 6 violation.avi', threads=0)
ret = core.std.Trim(clip=ret, first=10000, length=5000)

src = ret
c = core.avs.MSuper(c1=src)
b1v = core.avs.MAnalyse(c1=c, delta=1, isb=False)
f1v = core.avs.MAnalyse(c1=c, delta=1, isb=True)
b2v = core.avs.MAnalyse(c1=c, delta=2, isb=False)
f2v = core.avs.MAnalyse(c1=c, delta=2, isb=True)
ret = core.avs.MDegrain2(c1=src, c2=c, c3=b1v, c4=f1v, c5=b2v, c6=f2v)
ret.output(sys.stdout, y4m=True)

[active1]

wow, vapoursynth is really awesome!
thank you Myrsloik :)
Q: can i load avsi scripts with it?

I'm not so optimistic about avisynth mt...

can you explain 'why' a little?

[hajj_3]

can you explain 'why' a little?

because there has been virtually no development on avisynth for ages. Vapoursynth is already good and judging by the speed of changes i'm sure we'll have a great version ready within a few months with lots of added features.

[Myrsloik]

The website has stopped sleeping. R3 has been released. It has greatly improved avisynth plugin compatibility and many other fixes. Most notably mvtools works perfectly now so someone crazy could try porting the QTGMC script.

Next on the list is probably adding more things related to frame properties so they can become useful, including a port of ffms2.

[-Vit-]

I've been thinking about the QTGMC port, if I get some time this weekend I'll have a go.