Vapoursynth

[Myrsloik]

Originally Posted by RTW47

import vapoursynth as vs
core = vs.get_core()
video = core.avisource.AVISource(path=r'D:\ULRG.avi')
video.set_output()

Python exception: 'list' object has no attribute 'set_output'
Traceback (most recent call last):
File "vapoursynth.pyx", line 1148, in vapoursynth.vpy_evaluateScript
(src\cython\vapoursynth.c:18441)
File "D:\test.vpy", line 4, in <module>
video.set_output()
AttributeError: 'list' object has no attribute 'set_output'

#vapoursynth r23 on win32
#edit:. ~for me it looks like problem(s) only occur then loading Ut Video RGB (ULRG) or RGBA (ULRA)

It's probably working. Since you have alpha (or avisource guessed alpha more likely in the first case) the return isn't a single clip. It's an array of two clips, one with rgb video and one gray clip containing the alpha channel.

You most likely intended to do:

video[0].set_output()

[RTW47]

@Myrsloik, thanks for the note.
got video preview in vdub working the following way:
...
video = core.resize.Bicubic(video[0], format=vs.COMPATBGR32)
video = core.std.FlipVertical(video) #converting with COMPATBGR32, still flips output upside down;
video.set_output()

[Myrsloik]

I guess it's time for a status update. I've been busy working on the mvtools replacement and that's why there haven't been any other visible activity. It's still far from even being a proof of concept so don't expect it to be done soon.

Unfortunately I'm probably going to be too busy to make any real progress until July.

[pokazene_maslo]

Myrsloik: good luck with those mvtools, i'm looking forward to them

[LoRd_MuldeR]

Is there are particular reason why VapourSynth explicitly requires Python 3.3 and won't work with Python 3.4?

I'm asking, because I had installed the latest official Python 3.x, which current is Python 3.4.0. But the VapourSynth installer refused to install, until I installed Python 3.3 as well.

[sl1pkn07]

use waf 1.7.15 instead of waf download by bootstrap

[Myrsloik]

Originally Posted by LoRd_MuldeR

Is there are particular reason why VapourSynth explicitly requires Python 3.3 and won't work with Python 3.4?

I'm asking, because I had installed the latest official Python 3.x, which current is Python 3.4.0. But the VapourSynth installer refused to install, until I installed Python 3.3 as well.

Because 3.3 was the most recent branch when I made the last release on Windows. To compile it for more than one python version at a time is simply too much work. I already need to prepare both 32 and 64 bit binaries.

So which python version do you want to see the next release work with? 3.3 like now or 3.4 since it's the latest?

[LoRd_MuldeR]

Originally Posted by Myrsloik

Because 3.3 was the most recent branch when I made the last release on Windows. To compile it for more than one python version at a time is simply too much work. I already need to prepare both 32 and 64 bit binaries.

So Python sub-versions like v3.3 and v3.4 are not binary compatible and it's really not possible to make a VapourSynth binary that works with both? Or is that more an installer issue?

(I would have expected that Python v2.x and v3.x are not compatible, but v3.x sub-versions should be - at least if they follow the rules of semantic versioning!)

Originally Posted by Myrsloik

So which python version do you want to see the next release work with? 3.3 like now or 3.4 since it's the latest?

Unless there are any known regressions, I would probably go with the latest release?

[Myrsloik]

Originally Posted by LoRd_MuldeR

So Python sub-versions like v3.3 and v3.4 are not binary compatible and it's really not possible to make a VapourSynth binary that works with both? Or is that more an installer issue?

It's a python issue, I think. Or at least a windows python/cython one. All modules compiles with cython link against a specific python version. There are actually sometimes quite big api changes between python releases even if the numbers don't hint at it.

I'll make one more maintenance release using python 3.3 and then I'm going to switch.

[itzkin]

Hello
First I want to say that Vapoursynth is great. While I've only just started, I think it has huge potential.

I have 2 questions:
1) My clips get no audio?
In Avisynth there is FFVideoSource(clip) and FFAudioSource(clip). In Vapoursynth I know only of core.ffms2.Source(). Maybe there is another function I don't know about and can't find in the documentation?
Speaking of which are there any other sources of information except this thread and vapoursynth.com?

2) While I managed to get it working, I am still not sure what happens when I use the VSFS? Reading about Avisynth it was relatively easy for me to grasp the idea that the script is faking as a video file for the next piece of software, but now I am getting confused. How viable is VSFS in a web environment?

[nu774]

Linked python API library is controlled by pragma in pyconfig.h in case of MSVC.
By adding Py_LIMITED_API definition, generic python3.lib will be picked (this can be done by adding define_macros to setup.py).

HOWEVER, this doesn't work anyway. Generated C source (by Cython) seems to have references to _typeobject related things that is not visible when Py_LIMITED_API is defined.

[Reel.Deel]

Originally Posted by itzkin

I have 2 questions:
1) My clips get no audio?
In Avisynth there is FFVideoSource(clip) and FFAudioSource(clip). In Vapoursynth I know only of core.ffms2.Source(). Maybe there is another function I don't know about and can't find in the documentation?...

VapourSynth only supports video.

[itzkin]

Originally Posted by Reel.Deel

VapourSynth only supports video.

Might be a good idea to have that mentioned in the first post or anywhere on its website.

[foxyshadis]

Originally Posted by itzkin

2) While I managed to get it working, I am still not sure what happens when I use the VSFS? Reading about Avisynth it was relatively easy for me to grasp the idea that the script is faking as a video file for the next piece of software, but now I am getting confused. How viable is VSFS in a web environment?

VSFS allows applications that don't understand VS to see a plain avi file instead, that is a real uncompressed avi to the app. VSFS (via Pismo, which makes writing filesystem filters much easier) intercepts all of the read calls and inserts its own fake data to create a simulacrum of an avi. AVFS works the same way.

[foxyshadis]

OK, getting VS to build and run was one of the least fun experiences in a while, thanks in no small part to python, but now that I have it up and running I can start submitting a few patches. First, boosting the avisynth compatibility library to read all cpu levels avisynth supports, via VS's already-existing detection. (Allows JpegSource to run, perhaps others.)

[Myrsloik]

Originally Posted by foxyshadis

OK, getting VS to build and run was one of the least fun experiences in a while, thanks in no small part to python, but now that I have it up and running I can start submitting a few patches. First, boosting the avisynth compatibility library to read all cpu levels avisynth supports, via VS's already-existing detection. (Allows JpegSource to run, perhaps others.)

Is there any way I could convince you to make it pull requests on github? I can easily merge and comment patches even while I'm out travelling that way. If you don't this won't be applied for many weeks.

The patch itself is ok if you remove the

+	if (cpuf.fma3)   ; // no equivalent
+	if (cpuf.avx2)   ; // no equivalent

lines since they're dead code that will generate warnings.

If you tried to build it on linux recently there probably are some problems since lachs0r recently replaced most of the build system. Just create bugs for any odd stuff you find and he'll try to fix it.

[jackoneill]

Originally Posted by foxyshadis

OK, getting VS to build and run was one of the least fun experiences in a while, thanks in no small part to python, but now that I have it up and running I can start submitting a few patches. First, boosting the avisynth compatibility library to read all cpu levels avisynth supports, via VS's already-existing detection. (Allows JpegSource to run, perhaps others.)

Some of your lines are indented with tabs.

[foxyshadis]

Never used pull requests, hope this is how you do it.

Originally Posted by jackoneill

Some of your lines are indented with tabs.

Oops, I thought I caught all of those. Thanks.

The build problems were dependency building problems (getting ffmpeg and python to build), which never fully worked even with a cross-compile, in the end I just picked up pre-built dev builds. Eventually I'll get them going. The rest was figuring out more about how pyd extensions work, I did learn a lot.

The core Vapoursynth.dll project in MSVC links to the libraries libswscale.a and libavutil.a, but using those, I consistently got dll import problems. I had to change them to swscale.lib and avutil.lib from zeranoe's builds to get them to link right, otherwise it was looking for sws imports in libavutil.dll (maybe a static build would avoid this problem? I used dynamic libraries). When I hunted for answers on stackoverflow, it seems to be a problem with library file formats. Maybe 2013 Update 2 will fix that.

[YamashitaRen]

Hello.
I'm trying to compile vapoursynth on ARM but waf absolutely wants to use -msse2 ...
How can I disable this switch ?

Here is the config.log : http://pastebin.com/f83FKA9g
Thanks

edit : wrong config.log, now it's corrected

[Myrsloik]

VapourSynth R24 test 2
Will be released as is unless someone finds issues or suggests simple awesome features.
Needs Python 3.4
Things that could use extra testing: vivtc and vspipe

Changes:

r24:
vsvfw now properly returns an error message when no output has been set instead of silently failing
fixed a reference leak in vsscript
vspipe has a new argument for passing on values to the script environment from the command line 
vspipe now has improved command line parsing and short forms, however old command lines will have to be modified to work
re-added clip.output()
fixed a filter error propagation issue
mixed improvements to vivtc (nodame)
fixed mac compilation of genericfilters
added FreezeFrames, DuplicateFrames and DeleteFrames, they can all delete/duplicate/freeze multiple frames with one command (nodame)
mixed documentation improvements (nodame)
fixed tracking of memory usage that was broken in r22 (nodame)
vivtc now uses framedifference internally and runs completely in parallel, also minor metric reporting fixes (nodame)

I'M BACK!

THIS PROJECT ISN'T EVEN HALF AS DEAD AS CERTAIN OTHER PROJECTS!