Vapoursynth

[Myrsloik]

Looks fairly easy to adapt, I suppose. However personally I'd rather work on more general filters than <insert very specific camera model here> raw format readers.

I'll help anyone who tries to write such a source filter.

[tin3tin]

Looks like they are aiming at the more common CinemaDNG as the format they what to convert to, but the Raw format hasn't found its final format yet I guess. What about the bitrate. What bitrates can Vapoursynth handle/convert to?

[Myrsloik]

Looks like they are aiming at the more common CinemaDNG as the format they what to convert to, but the Raw format hasn't found its final format yet I guess. What about the bitrate. What bitrates can Vapoursynth handle/convert to?

Uh? What?

VapourSynth only deals in uncompressed video, just like avisynth.

[qyot27]

How exactly is output treated now? With a generic SVN build of r508 on the Athlon64 / Ubuntu 13.04 64-bit system I have access to:

Script (going off of the example in doc/):
#!/usr/bin/python3
import vapoursynth as vs
import sys
core = vs.get_core()
core.std.LoadPlugin("/usr/local/lib/vslsmashsource.so")
v = core.lsmas.LibavSMASHSource("testing.mp4")
v.set_output()

Error:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "vapoursynth.pyx", line 534, in vapoursynth.VideoNode.set_output (build/temp.linux-i686-3.3/pyrex/vapoursynth.c:9067)
vapoursynth.Error: 'Internal environment id not set. Was set_output() called from a filter callback?'

It does it with FFMS2 as well, so it doesn't seem to be plugin related (unless it's something deeper that plugins now need to account for?). The version of Cython is either 0.17.4 or 0.19.1; it throws the same error with either one of them.

[Myrsloik]

You need to use vspipe (which isn't added to the build system yet). Poke zor harder to catch up with my changes. I'll make a windows release tomorrow unless something unexpected happens and update the docs.

[sl1pkn07]

when make waf test (r508)

http://sl1pkn07.no-ip.com/paste/view/4e7ce5cd

greetings

[Myrsloik]

Have a test version of R19 (https://dl.dropboxusercontent.com/u/73468194/vapoursynth_r19_test.exe). I didn't really test it enough to call it a release yet but I think it works.

The biggest new thing is that it has a sane api for evaluating scripts and getting frames. Someone could make an editor similar to avspmod now... probably. Or actually embed it into another application.

Major changes in your scripts:
The python module now uses a singleton pattern:
vs.Core() => vs.get_core()
The core will be created with the options passed to the first get_core() call.
clip.output() and last have been replaced by clip.set_output() to make it uniform. Use vspipe.exe to pipe the contents of a script to stdout/whereever.

And test VSFS. I didn't really do that yet.

Changes:
r19:
calls to the getFrame() function inside vapoursynth can never deadlock now, the thread handling is also slightly improved
fixed a bug in the cache that would stop it from freeing all its frames when memory is needed, fixes an out of memory error reported by Chikuzen
output is no longer determined by setting the last variable in __main__, instead clip.set_output(int index = 0) is used to set which clip(s) are exported
fixed some memory leaks in the internal filters when they're freed (jackoneill)
now properly initializes blankclips to all 0 when no values are given
added proper const declarations now that cython supports it, cython 0.18 or later required to build the extension now
fixed get_write_ptr() in python to actually return a write pointer
fixed the lut and lut2 filters for > 8 bit formats (ADub)
various minor fixes to vivtc
removed clip.output() since it's a bad design decision, now a command-line program called vspipe can be used to pipe or write raw video output
renamed newMap() to createMap() to match the naming of all other functions
list_functions() renamed to get_plugins() for the core and get_functions() for namespaces, it also returns a dict instead of a string now
removed the unmentioned and unused link option for filter arguments as it is completely pointless and similar functionality may be implemented anyway
there's now a sane external api available for embedding in other applications, see vsscript.h and vsvfw for an example
now a singleton pattern is used for the core in python scripts, use vs.get_core() to get a reference to it
clip.get_frame() now throws an exception when out of bounds frames are requested
fixes a reference leak in the VideoProps python class
now ignores functions with . in their argument string for avisynth compatibility, this makes warpsharp mostly compatible

[LoRd_MuldeR]

Thanks for adding vspipe, that should make things much easier!

[sl1pkn07]

howto build vspipe in linux (wine)?

[Myrsloik]

What does wine have to do with linux?

[sl1pkn07]

then howto build vspipe? no need wine sources (to build on linux to linux)?

[jackoneill]

then howto build vspipe? no need wine sources (to build on linux to linux)?

No, you don't need wine for that.


clang++ -Wall -Wextra -Wno-unused-parameter -o libvsscript.so -shared -fPIC vsscript.cpp -I../../include -I../../build/temp.linux-x86_64-3.3/pyrex/ `pkg-config --cflags python3` `pkg-config --libs python3 vapoursynth`

and then

clang++ -Wall -Wextra -Wno-unused-parameter -o vspipe -fPIC vspipe.cpp -I../../include `pkg-config --cflags QtCore` -L../vsscript/ -lvsscript `pkg-config --libs QtCore`

Something like that. You can guess in what folders to run those.

[sl1pkn07]

thanks jackoneill

EDIT: none, don't see the last commit

greetings

[vdcrim]

Some issues of varying importance:


VfW: Reloading a script (e.g. F2 on VirtualDub) that loads any plugin will throw an exception 'XXX already loaded' (new in r19).


AddBorders: if the 'color' parameter is not given, a random color different each time is applied instead of [0, 0, 0] (AddBordersData's color is not initialized).


Calling VapourSynth from Python may crash

Not sure if this can be called a VapourSynth bug, but anyway: trying to use vsscript.dll (with ctypes) or evaluate the Avisynth script 'AviSource("script.vpy")' from Python may cause the process to crash at Py_Initialize depending on the environment. It seems that sys.path is populated at the Py_Initialize call from the caller's directories, not from Python 3.3.

Example of crash (Python 2):
import ctypes
ctypes.windll.vsscript.vseval_init()

I haven't managed to fully make clear this, but here are some notes:



If the Python application is wrapped with py2exe or similar all works as expected.
If not, the crash happens even if the environment variables PYTHONHOME and PYTHONPATH are not set.
If then PYTHONHOME is set pointing to the Python 3.3's directory, it works OK. I guess the same thing would happen if Py_SetProgramName is called before Py_Initialize.


If there's not a clean way of solving this then don't bother. I found the issue playing around without a defined purpose with the new vsscript API. If I or someone else adds VS support to AvsPmod it'll probably be by porting it to Python 3 (which is not possible yet) and using the included bindings instead.

[Myrsloik]

Interesting lump of bugs. I guess I'll rework the singleton thing a bit to avoid the issues.

The loading vsscript in python one will be an interesting one to try to figure out. Is this only when the python versions of vs and the loading script are different?

I suspect it's python that doesn't handle two different versions being loaded in the same process well. Exactly what did you wrap with py2exe?

[Chikuzen]

from VSScript.h

// Initialize the available scripting runtimes, returns non-zero on failure
VS_API(int) vseval_init(void);


I wasted my time about 30 minutes by this typo :(

[Myrsloik]

Huh? I though i wrote the code to work like the comment says. Guess I'll check it when i get home.

[vdcrim]

The loading vsscript in python one will be an interesting one to try to figure out. Is this only when the python versions of vs and the loading script are different?

Now that I try it with Python 3.3, it throws an 'OSError: exception: access violation reading 0x00000008', so sys.path is not the only problem.

If the script is called with Python 2.7 vsscript tries to load the Python resources from it:
Fatal Python error: Py_Initialize: unable to load the file system codec
File "C:\Program Files (x86)\Python27\lib\encodings\__init__.py", line 123
raise CodecRegistryError,\
^
SyntaxError: invalid syntax

Here's the incomplete bindings I wrote for playing around, in case it may be useful: https://gist.github.com/vdcrim/5891445
(https://gist.github.com/vdcrim/5891445)

I suspect it's python that doesn't handle two different versions being loaded in the same process well. Exactly what did you wrap with py2exe?
AvsPmod, either by adding the ctypes code to the application or as a macro script.

Also note that it also fails with 'AviSource("script.vpy")': if not using a py2exe build, it will crash.

Huh? I though i wrote the code to work like the comment says. Guess I'll check it when i get home.
I can confirm that Chikuzen is right.

[Myrsloik]

Have another test version (https://dl.dropboxusercontent.com/u/73468194/vapoursynth_r19_test2.exe).

It fixes everything reported apart from the odd python in python issue. I could really use some help with that one...

Changes: vseval_getCore(handle) <- now needs a script handle as argument
I also changed it so every script environment gets its own core which fixes a lot.
I simply changed the comment for vseval_init() to match current behavior
The color in addborders is now zero initialized.

Report anything else you find, I want this to be a working release once it's done.

[sl1pkn07]

stop build vspipe

http://sl1pkn07.no-ip.com/paste/view/0d18ac60

greetings

[Chikuzen]

>>> import vapoursynth as vs
>>> core = vs.get_core()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "vapoursynth.pyx", line 777, in vapoursynth.get_core (src\cython\vapoursy
nth.c:12897)
vapoursynth.Error: 'Internal environment id not set. Was get_core() called from
a filter callback?'
>>>

what's 'Internal environment id' ?

[Myrsloik]

>>> import vapoursynth as vs
>>> core = vs.get_core()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "vapoursynth.pyx", line 777, in vapoursynth.get_core (src\cython\vapoursy
nth.c:12897)
vapoursynth.Error: 'Internal environment id not set. Was get_core() called from
a filter callback?'
>>>

what's 'Internal environment id' ?

I forgot that scripts could also be called from outside of vsscript. I'll post a third test version a bit later today.

[Myrsloik]

Here's a third test (https://dl.dropboxusercontent.com/u/73468194/vapoursynth_r19_test3.exe).

Changes:
Possibly fixed the "python in python" crash, now it at least gets past vseval_init() on my computer (seemed to be caused by differences in GIL state)
Fixed the error that happend when not running scripts through vsscript
VSScript tells python to no install its signal handlers when loaded
Fixed the fps printed in vspipe's info

[mastrboy]

Myrsloik: What are the advantages of running a native compiled vapoursynth plugin versus loading a plugin with core.avisynth.LoadPlugin() ?

[vdcrim]

Updated list of head-scratchers:

The sys.path thing (for both vsscript and VfW). Other result of this (because is fixed by setting PYTHONHOME): if vsscript is called from Python 3.2 it crashes at vseval_evaluateScript.
Issues if vsscript is called from (and only from) Python 3.3: the OSError exception at vseval_init is fixed in test3, vseval_evaluateScript also passes (the gist linked a bit above is now Python 3 compatible) but the process gets stuck at vseval_finalize.

[Myrsloik]

Myrsloik: What are the advantages of running a native compiled vapoursynth plugin versus loading a plugin with core.avisynth.LoadPlugin() ?

If you don't need any features beyond what avisynth 2.5 offers and the plugin can't be easily changed to a better threading model (rare), nothing.

The key here is that x64 builds for windows are coming in a bit and then old avisynth stuff just won't work. (and don't think avisynth x64 plugins is the answer, since they're usually "delete key" ports and run slower than the 32-bit equivalents)

A properly written vs plugin also has the advantage of being compiled/used on any OS. I think of this as a new start where I and some other people slowly port/rewrite the most popular parts of avisynth's filters so they finally work in a modern environment everywhere...

[Chikuzen]

BTW, where did this feature go?
list_functions() renamed to get_plugins() for the core and get_functions() for namespaces,
it also returns a dict instead of a string now
new list_functions() is hard to use.

[Myrsloik]

BTW, where did this feature go?

new list_functions() is hard to use.

Hard to use in what way? What do you want changed? Should I restore the old list_functions() too for an easier to read format?

[Myrsloik]

Have a fourth test version (https://dl.dropboxusercontent.com/u/73468194/vapoursynth_r19_test4.exe).

This version restores list_functions(). get_functions()/get_plugins() is available to get dicts which are easier to deal with if programs want to enumerate everything.
It also fixes the "python in python" issue for python 3.3 and kinda other versions (insert huge asterisk here about vseval_finalize() hanging).

Keep testing. At this rate this will actually be a fairly stable release.

[Myrsloik]

Is the bug in Expr for > 8 bit formats reported by 06_taro (http://forum.doom9.org/showthread.php?p=1627283#post1627283) not to be fixed yet?

BTW, could the 'planes' argument of Lut/Lut2 be set to [0, 1, 2] by default(all planes will be processed), thus make it an optional argument?

I completely missed that expr was also mentioned. Will take a look at it tonight. Changing the default also makes sense i guess.

[zettai]

Has anyone managed to get access to a frame's image with vapoursynth via a numpy array or a pillow image or similar?

[Chikuzen]

Has anyone managed to get access to a frame's image with vapoursynth via a numpy array or a pillow image or similar?

I have previewed using PIL before since there was no VFW module at that time.


#vsshow.py
import vapoursynth as vs
from ctypes import *
from PIL import Image

def show(core, clip, frame_number, vflip=1):
format = clip.format.id
width = clip.width
height = clip.height
if format == vs.GRAY16:
clip = core.resize.Point(clip, width, height, vs.GRAY8)
if format != vs.GRAY8 and format != vs.RGB24:
clip = core.resize.Bicubic(clip, width, height, vs.COMPATBGR32)

format = clip.format.id
planes = range(clip.format.num_planes)
frame = clip.get_frame(frame_number)
data = [(frame.get_read_ptr(p), frame.get_stride(p)) for p in planes]
buff = [b'\0' * data[p][1] * height for p in planes]
for p in planes:
memmove(buff[p], data[p][0], data[p][1] * height)

if format == vs.COMPATBGR32:
mode, src = 'RGBA', 'BGRA'
else:
mode, src = 'L', 'L'
img = [Image.frombytes(mode, (width, height), buff[p], 'raw', src,
data[p][1], vflip) for p in planes]
if len(planes) != 1:
img = Image.merge('RGB', (img[2], img[0], img[1]))
else:
img = img[0]

img.show()

[Chikuzen]

@Myrsloyk
Would you add a function like avisynth's "Import" for VSScript?
It is annoy that the code for preparing a buffer, opening and reading a file and closing it must be written each time.

[Myrsloik]

@Myrsloyk
Would you add a function like avisynth's "Import" for VSScript?
It is annoy that the code for preparing a buffer, opening and reading a file and closing it must be written each time.

I guess I'll add a function to evaluate a script file as well.

Anyway, Zor finally updated the build system and ported VapourSynth to powerpc and arm. Have fun testing it on your ancient mac or something.

[vdcrim]

AviSynth's Import does a pair of extra things besides opening and evaluating the file:

Change the working directory to the script's parent directory before evaluating it (to allow use of relative paths).
Set some global variables: ScriptName, ScriptFile, ScriptDir.

Will VapourSynth do something similar? Maybe by passing an optional filename string to vseval_evaluateScript. That way future applications using evaluate instead of import won't have to care about mirroring this behaviour themselves.

[Groucho2004]

AviSynth's Import does a pair of extra things besides opening and evaluating the file:

Change the working directory to the script's parent directory before evaluating it (to allow use of relative paths).

No it does not. It sets the current directory to the directory in which the script resides.

[Chikuzen]

AviSynth's Import does a pair of extra things besides opening and evaluating the file:

Change the working directory to the script's parent directory before evaluating it (to allow use of relative paths).
Set some global variables: ScriptName, ScriptFile, ScriptDir.

Will VapourSynth do something similar? Maybe by passing an optional filename string to vseval_evaluateScript. That way future applications using evaluate instead of import won't have to care about mirroring this behaviour themselves.

My wish is contracting line 186 to 209 of this code (https://github.com/chikuzen/VapourSource/blob/master/src/VapourSource.cpp) to four lines like

if (vseval_new_function(&se, source)) {
env->ThrowError("VapourSource: failed to evaluate script.\n%s",
vseval_getError(se));
｝


of cource, without QtCore.

[vdcrim]

No it does not. It sets the current directory to the directory in which the script resides.
Isn't that what I said? :confused:

On second thought adding that functionality to vseval_evaluateScript may be a bad idea and doesn't solve the general problem: import might do things besides opening and evaluating the script (not necessarily limited to what AviSynth currently does), and someone using evaluate (because there's not file) would have to check the code and implement it themselves. Then the best would be adding to the API something like ImportFile and ImportBuffer instead of a single import.

[Groucho2004]

Isn't that what I said? :confused:
No. The script's parent directory is not the script's directory.

[Myrsloik]

I guess I'll add two new functions, vseval_importFile(&se, filename) and vseval_importBuffer(&se, scriptBuffer, imaginaryFilename) to do the things you mentioned.

I still want to keep the original function as well in case someone wants to have a different behavior.

[vdcrim]

No. The script's parent directory is not the script's directory.
Both are often used interchangeably. It could be just a common mistake though...

I still want to keep the original function as well in case someone wants to have a different behavior.
I agree.

[vdcrim]

It would be worth adding a comment somewhere in the header files saying that strings are always encoded/decoded with UTF-8.

[qyot27]

How do we set the correct python install so waf doesn't get confused? The addition of vsscript to the build system altered the detection method, and now it can only find 2.7.4 on my system. Setting it back to the old python detection allows it to pick up on 3.3.1, but it doesn't really solve it because the build process fails when it gets to vsscript.

I tried setting an alias so that 'python' is detected as python3, but waf still picks 2.7.4.

[Myrsloik]

PYTHON=python3 ./waf...
I think that will work. Note that i haven't managed to build it myself on Mac yet. I've also mentioned the python detection issues to zor so he should get around to fixing it soon.

[Adub]

I was able to build rev-513 on my Macbook Pro a little while back, but I haven't tested the latest updates quite yet (should be able to soon). Internet's been a little spoty recently so I haven't had a chance to sync yet.

That, and I also use a virtualenv for my dev purposes with just python3 loaded.

[Myrsloik]

I was able to build rev-513 on my Macbook Pro a little while back, but I haven't tested the latest updates quite yet (should be able to soon). Internet's been a little spoty recently so I haven't had a chance to sync yet.

That, and I also use a virtualenv for my dev purposes with just python3 loaded.

I did get it to build on mac now. Simply install qt, python3 and yasm using brew. Then install cython one way or another. Do PYTHON=python3. /waf... For all build commands.

Also, the project has moved to github now. Enjoy the absolutely zero difference in development efficiency...

[Adub]

I did see some issues when running ./waf test, even with PYTHON=python3. This is on Ubuntu 12.04, rev 530.

Here is my output:

blah@u1c6f650423c14ff77388:~/code/vapoursynth$ PYTHON=python3 ./waf test
Waf: Entering directory `/home/blah/code/vapoursynth/build'
Traceback (most recent call last):
File "/home/blah/code/vapoursynth/.waf-1.7.11-edc6ccb516c5e3f9b892efc9f53a610f/waflib/Scripting.py", line 97, in waf_entry_point
run_commands()
File "/home/blah/code/vapoursynth/.waf-1.7.11-edc6ccb516c5e3f9b892efc9f53a610f/waflib/Scripting.py", line 153, in run_commands
ctx=run_command(cmd_name)
File "/home/blah/code/vapoursynth/.waf-1.7.11-edc6ccb516c5e3f9b892efc9f53a610f/waflib/Scripting.py", line 146, in run_command
ctx.execute()
File "/home/blah/code/vapoursynth/.waf-1.7.11-edc6ccb516c5e3f9b892efc9f53a610f/waflib/Scripting.py", line 351, in execute
return execute_method(self)
File "/home/blah/code/vapoursynth/.waf-1.7.11-edc6ccb516c5e3f9b892efc9f53a610f/waflib/Build.py", line 106, in execute
self.execute_build()
File "/home/blah/code/vapoursynth/.waf-1.7.11-edc6ccb516c5e3f9b892efc9f53a610f/waflib/Build.py", line 109, in execute_build
self.recurse([self.run_dir])
File "/home/blah/code/vapoursynth/.waf-1.7.11-edc6ccb516c5e3f9b892efc9f53a610f/waflib/Context.py", line 128, in recurse
user_function(self)
File "/home/blah/code/vapoursynth/wscript", line 393, in test
if subprocess.Popen([ctx.env.PYTHON, name]).wait() != 0:
File "/usr/lib/python2.7/subprocess.py", line 679, in __init__
errread, errwrite)
File "/usr/lib/python2.7/subprocess.py", line 1249, in _execute_child
raise child_exception
AttributeError: 'list' object has no attribute 'rfind'

[Adub]

Ahhh oops!! Never mind, didn't see the new Github repo. The latest checkout from there builds and tests completely successfully.

For those of you wondering, the new source URL is here : https://github.com/vapoursynth/vapoursynth

[buchanan]

Hello Myrsloik

I'm using the 4th r19 test version, and i'm trying to run an x264 encode using the stdout method. My command line is:

"C:\Program Files (x86)\VapourSynth\core\vspipe.exe" "C:\test\test.vpy" - -y4m | "C:\test\x264.exe" --crf 20 --output "C:\test\test.mkv" --demuxer y4m -

The encoding runs fine, but at the end I get this message:

http://img11.hostingpics.net/pics/880324crash.png

(vspipe.exe stopped working, close the program or debug etc)

The output file seems to be correct though

That didn't happen with the 1st r19 test version, I didn't try with the 2nd and 3rd

[Myrsloik]

Hello Myrsloik

I'm using the 4th r19 test version, and i'm trying to run an x264 encode using the stdout method. My command line is:

"C:\Program Files (x86)\VapourSynth\core\vspipe.exe" "C:\test\test.vpy" - -y4m | "C:\test\x264.exe" --crf 20 --output "C:\test\test.mkv" --demuxer y4m -

The encoding runs fine, but at the end I get this message:

(vspipe.exe stopped working, close the program or debug etc)

The output file seems to be correct though

That didn't happen with the 1st r19 test version, I didn't try with the 2nd and 3rd

It's a known issue. I just haven't gotten around to fixing it yet. Pressing ctrl-c will also make it crash. It shouldn't do anything bad to the output since it crashes after everything is done.