Vapoursynth

[Myrsloik]

Crashes with other y4m files as well, not with e.g. mov files. So I guess it's l-smash's fault?

Any other source filter for y4m?

Probably.

You could try you luck with vsrawsource (http://forum.doom9.org/showthread.php?t=166075) if you don't mind fidgeting around a bit with offsets.

FFMS2 may also work. If you're really lucky.

[sneaker_ger]

ffms2 fails, too. vsrawsource works perfectly, seems to even read the header - did not expect that.

[Adub]

Excellent! Congrats on the R22 release!

I'm especially excited about the Qt removal, as it will make compiling CUDA enhancements on Mac significantly easier.

Thanks for the hard work Myrsloik!

[Adub]

Hmm, I seem to be durping with the latest version of Vapoursynth.

I can't get vspipe to work properly on a i7 Ubuntu 13.10 machine, 16GB of RAM.


adub@adub-desktop:/usr/local/lib $ python3
Python 3.3.2+ (default, Oct 9 2013, 14:50:09)
[GCC 4.8.1] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import vapoursynth as vs
>>> core = vs.get_core()
>>> print(core)
Core
VapourSynth Video Processing Library
Copyright (c) 2012-2013 Fredrik Mellbin
Core r22
API r3

Number of Threads: 8
Add Caches: True
Accept Lowercase: False

>>>
adub@adub-desktop:/usr/local/lib $ vspipe -version
Failed to initialize VapourSynth environment
adub@adub-desktop:/usr/local/lib $



What am I missing?

Ooops! Figured it out! I hadn't built and installed the Cython modules yet. Everything works like a champ now!

[foxyshadis]

Is there a location for the autoloading of .py or .vpy scripts? I didn't see anything about this in the docs, and site-packages has a LOT of junk in it, so I'd prefer not to replicate that folder to all of my systems.

[Myrsloik]

Is there a location for the autoloading of .py or .vpy scripts? I didn't see anything about this in the docs, and site-packages has a LOT of junk in it, so I'd prefer not to replicate that folder to all of my systems.

Python itself already has enough import mechanisms. I haven't added any additional ones. You can put all VapourSynth scripts in their own sub directory with minimal effort. Consult the python documentation on modules and look up .pth files for some hints on how it can be structured.

By autoloading I assume you mean that you can use import to load the script.

[foxyshadis]

Python itself already has enough import mechanisms. I haven't added any additional ones. You can put all VapourSynth scripts in their own sub directory with minimal effort. Consult the python documentation on modules and look up .pth files for some hints on how it can be structured.

By autoloading I assume you mean that you can use import to load the script.

I was hoping something like .avsi scripts in the Avisynth plugins folder. If site-packages or manual loading with a path is the only way to go, I'll do that then.

[supernater]

I'm trying to install vapoursynth on Ubuntu 12.04. When I was able to run ./waf configure/build/install just fine. However, when I run...

PYTHON=python3 ./setup.py build

I get....

running build
running build_ext
cythoning src/cython/vapoursynth.pyx to build/temp.linux-x86_64-2.7/pyrex/vapoursynth.c

Error compiling Cython file:
------------------------------------------------------------
...
mtDebug = 0,
mtWarning = 1,
mtCritical = 2,
mtFatal = 3

ctypedef void (__stdcall *VSFrameDoneCallback)(void *userData, const VSFrameRef *f, int n, VSNodeRef *node, const char *errorMsg)
^
------------------------------------------------------------

src/cython/vapoursynth.pxd:153:84: Expected ')', found '*'

Error compiling Cython file:
------------------------------------------------------------
...
return str(self.value)

def __repr__(self):
return repr(self.value)

cdef void __stdcall message_handler_wrapper(int msgType, const char *msg, void *userData) nogil:
^
------------------------------------------------------------

src/cython/vapoursynth.pyx:94:68: Expected ')', found '*'
building 'vapoursynth' extension
x86_64-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I. -Isrc/cython -I/usr/include/python2.7 -c build/temp.linux-x86_64-2.7/pyrex/vapoursynth.c -o build/temp.linux-x86_64-2.7/build/temp.linux-x86_64-2.7/pyrex/vapoursynth.o
build/temp.linux-x86_64-2.7/pyrex/vapoursynth.c:1:2: error: #error Do not use this file, it is the result of a failed Cython compilation.
error: command 'x86_64-linux-gnu-gcc' failed with exit status 1


At first I thought it was because I was using an older version of cython. The default cython version on ubuntu 12.04 is 0.17.4 I updated my repo list to include the cython ppa and installed cython 0.19.2 and the same error occurs. Is there a configuration setting I'm missing? Thanks.

[qyot27]

You're not supposed to use the 'build' rule on the Cython binding.

python3 ./setup.py install
is enough. Or more preferably, the install for VapourSynth itself and the Cython binding should be:
sudo checkinstall --pkgname=vapoursynth --pkgversion="$(grep Version build/pc/vapoursynth.pc | \
sed 's/ /"/g' | cut -f2 -d "\"")"R-r"$(git rev-list --count HEAD)" --default --backup=no --fstrans=no \
--nodoc ./waf install

sudo checkinstall --pkgname=vapoursynth-cython --pkgversion="$(grep Version build/pc/vapoursynth.pc | \
sed 's/ /"/g' | cut -f2 -d "\"")"R-r"$(git rev-list --count HEAD)" --default --requires=vapoursynth \
--backup=no --fstrans=no --nodoc python3 ./setup.py install
(I can't remember why --nodoc is there)

Two separate packages generated by checkinstall so that both are registered in the package management system.

[supernater]

Your instructions worked. I can see the two packages installed in synaptic. However, the installation instructions say to test the installation by running...

./waf test

When I run this I get this error...

Waf: Entering directory `/home/supernater/Desktop/vapoursynth/build'
Traceback (most recent call last):
File "test/test.py", line 2, in <module>
import vapoursynth as vs
ImportError: libvapoursynth.so: cannot open shared object file: No such file or directory

Is this test necessary?

[qyot27]

I have no idea. But always remember to follow up the install of shared libraries with 'sudo ldconfig' - otherwise, the system won't be able to find the .so.

[supernater]

Thanks for the tip. It worked. I was able to run the tests, only two of the 39 failed.

Waf: Entering directory `/home/supernater/Desktop/vapoursynth/build'
..................................EE...
======================================================================
ERROR: test_suffleplanes_arg2 (__main__.CoreTestSequence)
----------------------------------------------------------------------
Traceback (most recent call last):
File "test/test.py", line 161, in test_suffleplanes_arg2
self.core.std.ShufflePlanes(clip, planes=[0, 1, 2], format=vs.YCOCG)
File "vapoursynth.pyx", line 1044, in vapoursynth.Function.__call__ (build/temp.linux-x86_64-3.3/pyrex/vapoursynth.c:16573)
vapoursynth.Error: ShufflePlanes: Function does not take argument(s) named format

======================================================================
ERROR: test_suffleplanes_arg3 (__main__.CoreTestSequence)
----------------------------------------------------------------------
Traceback (most recent call last):
File "test/test.py", line 165, in test_suffleplanes_arg3
self.core.std.ShufflePlanes(clip, planes=[1, 1, 2], format=vs.RGB)
File "vapoursynth.pyx", line 1044, in vapoursynth.Function.__call__ (build/temp.linux-x86_64-3.3/pyrex/vapoursynth.c:16573)
vapoursynth.Error: ShufflePlanes: Function does not take argument(s) named format

----------------------------------------------------------------------
Ran 39 tests in 0.721s

FAILED (errors=2)
Test test/test.py failed

Not sure what that means, but at least it found the .so file.

[Mystery Keeper]

That means argument of ShufflePlanes was renamed from "format" to "colorfamily", but the test wasn't updated.
As far as I understand, this commit (https://github.com/vapoursynth/vapoursynth/commit/068c6c463a50db63712dd1b3261ef0d87f149bb9) fixes it.

[supernater]

Yup that did it! All tests ran successfully!

[MeteorRain]

Had a script that calls 2 avisynth plugins / functions on a clip. On r19 it did not report frame not prefetched, but on r22 it does.

I have read your blog but couldn't find anything useful regarding to this change.

Is there anything I can do to quick fix the issue? like specify the prefetch frame list without rewrite the plugin.

FYI one of it is the overlay()

Thanks.

[Myrsloik]

Had a script that calls 2 avisynth plugins / functions on a clip. On r19 it did not report frame not prefetched, but on r22 it does.

I have read your blog but couldn't find anything useful regarding to this change.

Is there anything I can do to quick fix the issue? like specify the prefetch frame list without rewrite the plugin.

FYI one of it is the overlay()

Thanks.

The default for prefetching changed to make a bit more sense around r20 I think. It was necessary to fix the huge performance issues that would otherwise should up in decimate/tdecimate/any serious framerate changing filter. Now frames are only prefetched if a filter is known, before that the prefetching assumed that one input frame needed to be fetched. Sometimes not the right one...

Anyway, if it isn't slower don't bother doing anything. It's only a warning. If you simply want to overlay things you can usually use Lut2 or Expr to accomplish something similar.

[MeteorRain]

The default for prefetching changed to make a bit more sense around r20 I think. It was necessary to fix the huge performance issues that would otherwise should up in decimate/tdecimate/any serious framerate changing filter. Now frames are only prefetched if a filter is known, before that the prefetching assumed that one input frame needed to be fetched. Sometimes not the right one...

Anyway, if it isn't slower don't bother doing anything. It's only a warning. If you simply want to overlay things you can usually use Lut2 or Expr to accomplish something similar.
:thanks:

For overlay I'm using it's slicing part. I wrote a function to do the cropping & stacking manually, but still wonder if there are any better / faster methods.

Currently vapoursynth can't consume all the CPU resources. I have to run 2 tasks in parallel to archive 100% usage. I guess there's still some space to improve multi-thread performance.

Is it possible to add a "FIFO prefecher" inside a script if given all following operations are linear?

[Myrsloik]

:thanks:

For overlay I'm using it's slicing part. I wrote a function to do the cropping & stacking manually, but still wonder if there are any better / faster methods.

Currently vapoursynth can't consume all the CPU resources. I have to run 2 tasks in parallel to archive 100% usage. I guess there's still some space to improve multi-thread performance.

Is it possible to add a "FIFO prefecher" inside a script if given all following operations are linear?

I need to see the whole script you're using if you want more hints.

[MeteorRain]

I need to see the whole script you're using if you want more hints.

https://github.com/msg7086/MyECTools/blob/master/MyECTools.py

v = core.avs.MPEG2Source("main.d2v")
v = haf.QTGMC(v, Preset="super fast", SubPel=2, TFF=True, FPSDivisor=2)
v = core.avs.EraseLOGO(v, logoFile)
v = ect.ECSlice(v, l=1292, t=32, r=64, b=996, sp1=(lambda c: core.avs.fft3dGPU(c, sigma=4, plane=4)), spmode=1) # Also tried FFT3DFilter
#crop&resize etc


Core is initialized with threads=6, using 4c6t on i7 4770, CPU affinity enforced, CPU resources separated from x264 using pipe

[Myrsloik]

https://github.com/msg7086/MyECTools/blob/master/MyECTools.py

v = core.avs.MPEG2Source("main.d2v")
v = haf.QTGMC(v, Preset="super fast", SubPel=2, TFF=True, FPSDivisor=2)
v = core.avs.EraseLOGO(v, logoFile)
v = ect.ECSlice(v, l=1292, t=32, r=64, b=996, sp1=(lambda c: core.avs.fft3dGPU(c, sigma=4, plane=4)), spmode=1) # Also tried FFT3DFilter
#crop&resize etc


Core is initialized with threads=6, using 4c6t on i7 4770, CPU affinity enforced, CPU resources separated from x264 using pipe

I don't understand why you set thread affinity. I suspect that fft3dgpu is still the limiting filter in your script though. If you tell me what resolution the input clip is I can try running the whole thing myself a bit later.

[MeteorRain]

I don't understand why you set thread affinity. I suspect that fft3dgpu is still the limiting filter in your script though. If you tell me what resolution the input clip is I can try running the whole thing myself a bit later.
I set affinity for the process because it'll be faster than not to do so. Even way faster for some specific program. And I guess if it cannot consume all resources under 4c6t, it cannot do under 4c8t as well. Vice versa.

I also tried fft3dfilter but that doesn't make much difference.

The source was captured from TV and is 1920x1080 30i/1.001

Well, my (original) question was, if I see lots of "frame # not prefetched" where same frame number appears multiple time, does this mean that it is slower than it should be?

========== EDIT:
Well I'll try to read the source code and see if I can do something

========== EDIT2:
FYI the fft3dgpu has a function name of "fft3dGPU" which is not the same as in the prefetch list.

[Myrsloik]

========== EDIT:
Well I'll try to read the source code and see if I can do something

========== EDIT2:
FYI the fft3dgpu has a function name of "fft3dGPU" which is not the same as in the prefetch list.

Sigh... capiTAliZation. Here's a dll (https://dl.dropboxusercontent.com/u/73468194/VapourSynth.dll) with the proper prefetch name.

Replace the one in Python33\Lib\site-packages\vapoursynth and see if it speeds up.

[MeteorRain]

Sigh... capiTAliZation. Here's a dll (https://dl.dropboxusercontent.com/u/73468194/VapourSynth.dll) with the proper prefetch name.

Replace the one in Python33\Lib\site-packages\vapoursynth and see if it speeds up.

Not faster. Actually I found the bottleneck sort of from the source filter. Either mpeg2source or d2v.source uses ~12% even if I give them 4c8t and set threads=1 or 4 or 8. I suspect that these filters are single threaded.

[Myrsloik]

Not faster. Actually I found the bottleneck sort of from the source filter. Either mpeg2source or d2v.source uses ~12% even if I give them 4c8t and set threads=1 or 4 or 8. I suspect that these filters are single threaded.

Actually d2vsource should be multithreaded. Guess I'll have to try it myself and see what happens...

[Myrsloik]

Not faster. Actually I found the bottleneck sort of from the source filter. Either mpeg2source or d2v.source uses ~12% even if I give them 4c8t and set threads=1 or 4 or 8. I suspect that these filters are single threaded.

Are you sure you're using the latest version of d2vsource? It's the only remaining explanation I can think of (apart from d2vsource bugs/weird source file).

[Iznogûd]

I've succesfully encoded a short clip (1000 frames) using this simple script

import vapoursynth as vs
core = vs.get_core()
ret = core.ffms2.Source(source=r'test.mkv')
ret = core.std.AssumeFPS(ret, fpsnum=24000, fpsden=1001)
ret = core.std.Trim(clip=ret, first=2000, length=1000)
ret = core.resize.Spline(clip=ret, width=1280, height=720)
ret.set_output()

and this command line

"C:\Program Files (x86)\VapourSynth\core32\vspipe.exe" "test.vpy" - -y4m | D:\MeGUI\tools\x264\x264_64.exe --crf 19 --output "out_test.mkv" --demuxer y4m --stdin y4m -


However, when I try it with the 64 bit version,

"C:\Program Files (x86)\VapourSynth\core64\vspipe.exe" "test.vpy" - -y4m | D:\MeGUI\tools\x264\x264_64.exe --crf 19 --output "out_test.mkv" --demuxer y4m --stdin y4m -


it crashes at the very beginning with this message:

x264 [error]: could not open input file '-'
Error: fwrite() call failed when writing frame: 0, plane: 0, line: 12, errno: 22

Output 4 frames in 0.30 seconds (10.39 fps)

Phyton 3.3.3 (32 and 64 bits) on separate folders and Vapoursynth R22, but I also tried each version separately as well as the 32 and 64 bits x264 and the results are always the same: 32 bits work, 64 doesn't.

Am I missing anything obvious? :confused:

[Iznogûd]

Yes, it does:

Width: 1280
Height: 720
Frames: 1000
FPS: 24000/1001
Format Name: YUV420P8
Color Family: YUV
Bits: 8
SubSampling W: 1
Subsampling H: 1
Output 0 frames in 0.20 seconds (0.00fps)

Vspipe 32 yields up the same info. Furthermore, I'm able to mount the script and watch it OK.

Thanks for your help

[Myrsloik]

Yes, it does:



Vspipe 32 yields up the same info. Furthermore, I'm able to mount the script and watch it OK.

Thanks for your help

Odd, there's certainly no obvious problem here. The only other test I can think of is to do something like:
"C:\Program Files (x86)\VapourSynth\core64\vspipe.exe" "test.vpy" - -y4m > file.y4m
And then see if anything was written to the file after a few seconds.

[Iznogûd]

@Myrsloik:

Both versions do indeed write a file with .y4m extension, about 1.30 Gb, but whereas Mediainfo gives this log for the 32 bit one (which I can encode with x264),
General
Complete name : E:\test_vs\file32.y4m
Format : YUV4MPEG2
File size : 1.29 GiB
Duration : 41s 708ms
Overall bit rate : 265 Mbps

Video
Format : YUV
Duration : 41s 708ms
Bit rate : 265 Mbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Scan type : Progressive
Compression mode : Lossless
Bits/(Pixel*Frame) : 12.000
Stream size : 1.29 GiB (100%)

only sees the 64 bit as a mere big file (which x264 can't open):
General
Complete name : E:\test_vs\file64.y4m
File size : 1.29 GiB

I repeated the test after uninstalling everything (Python, Pismo & VapourSynth) and reinstalling the 64 bit versions only, but the result is the same.

Please let me know if you need me to perform further testing.

Thanks for your help.

[MasterNobody]

Iznogûd
Can you upload the first few MBs (5 MBs should be enough) of this bad y4m? Or look at it yourself with any HEX/text editor. The first two lines should start from "YUV4MPEG2" and "FRAME" i.e. should looks like:
YUV4MPEG2 W1280 H720 F24000:1001 Ip A1:1
FRAME
<some binary data>

[Iznogûd]

@MasterNobody

Indeed, the 64bit file shows two initial bytes (0a 0a) which are not present in the 32bit one.

13975

If I delete these two offending bytes with an hex editor, the file is happily accepted by x264. So it would seem that vspipe64 is writing the wrong header.

I think you've nailed it. :thanks:

[Myrsloik]

I forgot a debug printf in there. Here's a fixed x64 dll. (https://dl.dropboxusercontent.com/u/73468194/VapourSynth.dll) Remember to put it in <Python64>\Lib\site-packages\vapoursynth.

[Iznogûd]

Done! It works OK now.

Thank you very much for your help, folks.

[Adub]

Quick update on my merge of the latest mainline with my CUDA enhancements.

I'm about 80% of the way there. Unfortunately, CUDA's nvcc compiler is a bit of a...bugger when it comes to C++11 support. Normally this isn't a problem as long as I don't use C++11 constructs/headers in my .cu files. This the case for almost all of my files, except for two. One should be relatively easy to fix, the other not quite as easy.

In order to get around nvcc's C++11 issues, I need to isolate the bare CUDA work to it's own CUDA file, with my constructors in a separate, C++11 compatible .cpp file. The .cpp file will essentially act as a wrapper, allowing me to overload some of the central 'vscore' constructors while still allowing for proper compilation using C++11.

It's a bit unfortunate that I have to try and do it this way, but that's the way it's going to have to be until CUDA offers better C++11 handling (which it really should, but it handles it in a stupid way at times).

If you want to look at the latest version of the code, Myrsloik, just ping me. Not all of it is working yet (obviously) but it can give you an idea of what I'm doing.

[Adub]

Good news! I was able to handle all of the C++11 incompatibilities and get my branch back to a reliable, testable implementation.

I'm also in the process of getting Vapoursynth working on my Mac for additional testing purposes. I've got the master branch working and compiling and all tests are passing 100%, so I'll switch over to making sure my CUDA branch works on Mac as well.

Depending on how easy that is, I'm going to write up a quick testing tool/framework for automated performance analysis, so that I can track performance differences between CPU/GPU implementations and differences in performance between commits.

Just checking in.

[Mystery Keeper]

What exactly are you implementing in CUDA?

[Adub]

Essentially the core filters, and the associated memory management/control routines required to support a high performance CUDA GPU.

I ported over a section of the core filters for my Thesis work, but some still remain. That, and my earlier work became outdated with the move to C++11 from Qt.

Filters that see the most benefit are CPU-bound filters like Expr. Stuff like Transpose and LUT actually suffer a performance degradation when performed alone (since most of the time is spent transferring the data to and from the GPU), but it's possible to perform a variety of operations while keeping the data on the GPU, which eventually leads to a cumulative performance boost.

[Mystery Keeper]

Well, like you said, the bottleneck of GPGPU is data transferring between CPU and GPU memory. Filter would only gain performance boost if actual computing takes significantly more time than memory transfer. You'd do well to port dfttest, which uses FFT and windowing and what not. High complexity AND high parallelism potential. As for core filters - I don't know how you would "perform a variety of operations while keeping the data on the GPU" on an arbitrary filters chain. Are you making your own cache?

[Youka]

I tried to compile vapoursynth from github source on lubuntu 13.10 (virtualbox) yesterday, but got some problems:
- configure doesn't search for python3, just looking for the default python interpreter which is 2.7.5 (fix: changed symbolic link of '/usr/bin/python' from python2 to python3)
- build threw an error because of missing sse2 support in "src/filters/removegrain/clense.cpp" (fix: configure with disabled filters)
- test couldn't import vapoursynth, on some systems "/usr/local/lib" isn't visible for the runtime linker (fix: configure with changed installdir or added local directory to ldconfig)
Are 1) & 3) usual and 2) a new bug or am i doing something wrong?

[Adub]

1) A simple "PYTHON=python3 ./waf configure build" works just fine.
2) Missing SSE2 support? What processor are you presenting to your virt? Any processor made within the past 10 years has SSE2 support.
3) I've never seen this before, as long as I've installed the Cython modules using "./setup.py install" (possibly with sudo).

[Adub]

Well, like you said, the bottleneck of GPGPU is data transferring between CPU and GPU memory. Filter would only gain performance boost if actual computing takes significantly more time than memory transfer. You'd do well to port dfttest, which uses FFT and windowing and what not. High complexity AND high parallelism potential. As for core filters - I don't know how you would "perform a variety of operations while keeping the data on the GPU" on an arbitrary filters chain. Are you making your own cache?

You are correct, most speed boosts are only seen on computationally intensive filters.

As for my "variety of operations", yes, I do keep my own cache of sorts on the GPU. The GPU cache is tracked independently of the main CPU cache.

All frame transfers are dictated by the user using a function called TransferFrame. This keeps the transfer logic in one place and prevents sending data back and forth after every function execution.

Each filter identifies where the data is located for the particular frame and executes a GPU or CPU kernel accordingly. All GPU kernels are executed asynchronously using CUDA streams, which let the GPU schedule work as efficiently as possible, and sometimes operate on multiple planes at once depending on resources.

Example of what I'm talking about:

clip = ...
clip = core.TransferFrame(clip, 1)
clip = core.filterA(clip)
clip = core.filterB(clip)
clip = core.filterC(clip)
clip = core.TransferFrame(clip, 0)
clip = core.filterD(clip)
etc...


Filters A, B, and C operate on the clip's data entirely on the GPU, with Filter D operating on frame data on the CPU. That way you can mix and match filters that may not have GPU support with those that do.

[Youka]

1) Creating an alias is maybe the best solution, but it would be better when configure test for python3 too.

2) Error comes from emmintrin.h:
#ifndef __SSE2__
# error "SSE2 instruction set not enabled"
#else
...__SSE2__ isn't set by the compiler (-msse2 could solve it). The processor is surely not the problem.

3) Test still doesn't find the module. "ldd vspipe" shows an incompatibility too...

[Myrsloik]

A bonus question about your secret CUDA/GPU build...

Can it handle SLI/multiple graphics cards as well? I suspect you'd need to have a function to transfer between different GPUs as well to get around the latency.

[Myrsloik]

I tried to compile vapoursynth from github source on lubuntu 13.10 (virtualbox) yesterday, but got some problems:
- configure doesn't search for python3, just looking for the default python interpreter which is 2.7.5 (fix: changed symbolic link of '/usr/bin/python' from python2 to python3)
- build threw an error because of missing sse2 support in "src/filters/removegrain/clense.cpp" (fix: configure with disabled filters)
- test couldn't import vapoursynth, on some systems "/usr/local/lib" isn't visible for the runtime linker (fix: configure with changed installdir or added local directory to ldconfig)
Are 1) & 3) usual and 2) a new bug or am i doing something wrong?

1. Known issue due to how waf autodetects things, a note has been added to the installation instructions
2. Fixed in git right after you mentioned it
3. It's the way it is in the unixy world (or so I've heard)

[Adub]

Haha, I'd hardly call it secret : https://github.com/adworacz/vapoursynth/tree/cuda

Don't hate on all of the code yet, as I've got some refactoring and code cleanup to do after the C++11 merge, not to mention more filters to port.

Multiple cards is definitely something that I want to handle as well. I almost started implementing it on two massive Kepler machines during my thesis research, but I didn't have the time to do it before I had to graduate. So, multiple graphics card support is pending my getting a hold of a pair of GTX 780 Ti's. :D Those were the first consumer cards with fully unlocked CUDA cores based on the Kepler architecture.

That, and CUDA 6 offers some interesting support of a "universal memory" paradigm for GPU memory, which may make programming for multiple cards easier. That is something I will have to dig into more when I get a chance. I think I presented a few ideas in my thesis, but I'll have to remind myself of them again. :P

Edit: I think one idea I had was striping frames across GPUs, sort of a load balance technique. Of course, this mostly just works for spatial filters, but since the core filters are essentially spatial filters, it can work as a proof of concept.

[Mystery Keeper]

Adub, I'd recommend to wait for the new generation of nVidia cards coming in April. Not only they'll have three times more cores, but also some kind of memory improvements.

[Adub]

Do you have a link on details about the new cards? I'm curious to see what the differences are.

[Mystery Keeper]

http://www.itworld.com/hardware/397985/nvidias-next-generation-gpus-coming-sooner-expected
For example. You can google for GTX 800.

[lansing]

Is there any source filter that can open grf file created from graphicstudio?

[Myrsloik]

Is there any source filter that can open grf file created from graphicstudio?

No, I didn't adapt directshowsource from avisynth since I didn't think anyone would actually need it.