Vapoursynth

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

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

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 posted at pastebin. The scripting language doesn't *seem* that hard. But then again I'm just a monkey so I might be wrong.

[JEEB]

Originally Posted by Reel.Deel

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]

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

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]

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

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?

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

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

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

[TheFluff]

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

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]

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

http://forum.doom9.org/showpost.php?p=1589319&postcount=142

Only avisynth 2.5 plugins supported.