Vapoursynth

[Myrsloik]

Website:
http://www.vapoursynth.com/
VapourSynth ChangeLog
Documentation
List of all known plugins and scripts
VapourSynth Editor

[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]

Originally Posted by TheProfileth

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.

Originally Posted by TheProfileth

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]

Originally Posted by TheProfileth

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]

Originally Posted by mastrboy

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]

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

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.

Originally Posted by clsid

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.



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]

Originally Posted by The_Paya

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 was, compared to ASS/SSA.

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

[JEEB]

Originally Posted by mandarinka

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