Currently these filters are missing documentation:
VIVTC
AviSource
EEDI3
AssVapour
RemoveGrain/Repair

Most of it can be fairly easily created/adapted from their existing proto-filters.

There are several library such as PIL and numpy used for image manipulation in python. Add methods to export frames to PIL or numpy (zero memory copy possible) for easier use.

Or something else to help the poor plugin writers. Maybe expose the flags through the api.

Use LoadLibraryEx instead of messing with the working directory on windows when loading plugins (if the function is available).

Hi

└───╼ git describe --always
R19-315-g2acfebc

└───╼ git tag
R19
R20

greetings

Add vapoursynth to one of the most popular subtitling plugins. The developers are asking for help.

Doom9 post here:
http://forum.doom9.org/showthread.php?p=1637847&highlight=vapoursynth#post1637847

Since I have access to PPC hardware, might as well port VS to PPC/Linux.

Double check the locking so a filter can be created and destroyed every frame. Also add something similar to avisynth's Animate() if possible.

log: http://sl1pkn07.no-ip.com/paste/view/7dc7c0a8

archlinux 64bits

greetings

It seems the C-plugin gets a VSFuncRef object when a function parameter is delivered in the vpy script. I read the source code and find it seem to using vsapi->callFunc() with in and out parameters to use the function to caculate the result. So I wonder what to do if I want to pass a list/an array to the VSFuncRef object that the plugin gets from the script(which is in fact a function that uses a list as parameter in the script). Should I just use vsapi and append all the values needed by the list that the VSFuncRef would use, then just run vsapi->callFunc, or do something different to achieve my goal?

The most popular filter for use in avisynth denoising filters. Needed for QTGMC.

import vapoursynth as vs

c = vs.get_core()

src = c.d2v.Source("./vol 01.d2v", rff=True) # YUV420P8

blank = c.std.BlankClip(src, width=src.width_2, height=src.height_2, color=[128, 128, 128])

ret = c.std.ShufflePlanes([blank, src], planes=[0, 0, 0], format=src.format.color_family)

ret = c.ssiq.SSIQ(ret)

ret = c.std.ShufflePlanes([ret, src], planes=[1, 1, 2], format=src.format.color_family)

ret.set_output()

There should be a way to suppress all the non-fatal messages without redirecting stdout/stderr to null, or at least the one mentioned in the subject of this issue since there's no absolute need for the user specific plugin folder.

Make THE most complicated and appreciated avisynth script run natively.

Currently errors only fail to produce a frame, something that's allowed in vfw, but there's no way to report any other issue. It could be useful to substitute a frame with the error message or something similar.

Popping up a dialog with an error log could also be useful. (and somewhat evil)

Currently the default is always set to 1GB which is only reasonable for somputers with 2GB+ ram and running as a 32bit process. For 64bit it should probably be total ram-2GB or something (assuming 4GB ram or more).

The secret environment id should be pushed and popped on a stack and not simply overwritten.

CC=clang CXX=clang++ waf configure
waf build

The above fails when linking vspipe:

[25/25] cxxprogram: build/src/vspipe/vspipe.cpp.5.o -> build/vspipe
./libvapoursynth.so: error: undefined reference to 'dlclose'
./libvapoursynth.so: error: undefined reference to 'dlerror'
./libvapoursynth.so: error: undefined reference to 'dlopen'
./libvapoursynth.so: error: undefined reference to 'dlsym'
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Somehow waf doesn't add -ldl (or -lm for that matter):

[21/25] cxxshlib: build/src/core/asm/x86/check.asm.1.o build/src/core/asm/x86/cpu.asm.1.o build/src/core/asm/x86/expr.asm.1.o build/src/core/asm/x86/transpose.asm.1.o build/src/core/cachefilter.cpp.1.o build/src/core/cpufeatures.cpp.1.o build/src/core/exprfilter.cpp.1.o build/src/core/simplefilters.c.1.o build/src/core/vsapi.cpp.1.o build/src/core/vscore.cpp.1.o build/src/core/vsresize.c.1.o build/src/core/vsthreadpool.cpp.1.o -> build/libvapoursynth.so
12:34:44 runner ['clang++', '-Wl,-O1,--sort-common,--as-needed,-z,relro', '-Wl,-O1,--sort-common,--as-needed,-z,relro', '-shared', '-Wl,-Bsymbolic', '-Wl,-z,noexecstack', 'src/core/asm/x86/check.asm.1.o', 'src/core/asm/x86/cpu.asm.1.o', 'src/core/asm/x86/expr.asm.1.o', 'src/core/asm/x86/transpose.asm.1.o', 'src/core/cachefilter.cpp.1.o', 'src/core/cpufeatures.cpp.1.o', 'src/core/exprfilter.cpp.1.o', 'src/core/simplefilters.c.1.o', 'src/core/vsapi.cpp.1.o', 'src/core/vscore.cpp.1.o', 'src/core/vsresize.c.1.o', 'src/core/vsthreadpool.cpp.1.o', '-o', '/home/asdf/builds/vapoursynth/src/vapoursynth-build/build/libvapoursynth.so', '-Wl,-Bstatic', '-Wl,-Bdynamic', '-lQtCore', '-lswscale', '-lavutil', '-lavcodec']

-ldl and -lm are not present when compiling with gcc either, but it works anyway.

Vapoursynth is the latest from git, clang is 3.3, gcc is 4.8.1, python is 3.3.2, waf is 1.7.11. Operating system is 64 bit Arch Linux.

1. No way to return to the front page from the docs.
2. Github may appear behind links and frighten users

Waf will usually select python 2 even if 3.x is also installed. The workaround is to do PYTHON=python3 ./waf...

VS should be ported to ARM/Linux. This involves some build system changes to set the proper defines for ARM and a few preprocessor checks in the code.

Could also use optimized assembly.

Currently all plugins have to be manually loaded. Avisynth style autoloading would be desirable however this has a fairly high crash risk (as also seen in avisynth) for badly written plugins.

Completely broken filters will of course be blacklisted. Detected misbehaving filters should also be clearly reported.

when i run ./waf build,i got such error info:

./libvapoursynth-script.so：undefined reference to ‘PyString_FromString’
Build failed
-> task in 'vspipe' failed (exit status 1):
{task 140507158663696: cxxprogram vspipe.cpp.5.o -> vspipe}
['/usr/bin/g++', '-Wl,-Bsymbolic', '-Wl,-z,noexecstack', '-Wl,-Bsymbolic-functions', '-Wl,-z,relro', 'src/vspipe/vspipe.cpp.5.o', '-o', '/home/byron/src/vapoursynth/build/vspipe', '-Wl,-Bstatic', '-Wl,-Bdynamic', '-L.', '-L.', '-L/usr/lib/python3.3/config-3.3m-x86_64-linux-gnu', '-lvapoursynth', '-lvapoursynth-script', '-lQtCore', '-lswscale', '-lavutil', '-lavcodec', '-lpython3.3']

Been dragging this for too long. Needed so 16bit/float image formats can be easily opened.

Based on the same source but still quite a bit slower. For some reason...

Is anyone using it at all?

The changes in the core libraries from Qt 4.8 to Qt 5 are minimal so the code should compile with either one.

It could be useful to have good statistics over how much processing time is spent in individual filters when running a complex script.

Adding support for it is however a bit tricky since filters can be destroyed and created lots of times per game when frameeval is used.

Visualizing and reporting it could probably benefit from some kind of graph inspection support as well.

Plugins should have some way to know where they are stored on disk. This could be very handy for plugins loading additional libraries and other support files.

I wrote three patches for this issue.
http://code.google.com/p/vapoursynth/issues/detail?id=52

patches are here.
https://dl.dropboxusercontent.com/u/19797864/patch/0001-Lut2-fix-possibility-that-the-value-of-lut-comes-out.patch
https://dl.dropboxusercontent.com/u/19797864/patch/0002-Lut-Implement-to-take-a-function-and-evaluate-it-to-.patch
https://dl.dropboxusercontent.com/u/19797864/patch/0003-Lut2-Implement-to-take-a-function-and-evaluate-it-to.patch

Instead of creating a new filter object each time a filter is invoked in a script, check to see if a filter was invoked with the same arguments. If so, return a handle to the existing filter instead of creating a new one.

Many large scripts contain redundant filter invocations, especially if functions are used to structure logic. Eliminating duplicate filter instances saves memory and improves the effectiveness of caching.

Add major API version to the 3 public header files:
vapoursynth4.h
vshelper4.h
vsscript4.h

Add getAPIVersion() to vsapi. Will simplify a lot of things.

A createCore function where you can prevent autoloading of plugins.

Move plugin identifiers to vshelper and adopt consistent naming of things

Don't implement scanline based filters but adjust the API so it's possible to do later. For example require explicit declaration of node dependencies.

Additional Enums #570

Make it possible to cancel in progress requests to getFrameAsync? Return a proper future/promise style object instead?

Add automatic packing/unpacking to avs compat since compat formats are now removed. Easiest done by introducing packing/unpacking filters.

Improve plugin handling on windows to leak less memory

The possibility to register user functions with argument lists and export them through the core like a plugin. Add a user function namespace as an experiment?

Graph inspection - also add a processing time field that can be retrieved

Per core message handler

SUPPORT REMOVED since nobody uses this feature. It's really awkward to write filters that output multiple clips. Or more exactly kinda weird when both frames (such as main frame and alpha) are generated at the same time and therefore pushing both at once would be very helpful for performance.

All "void **instanceData" in filters should be changed to "void *instanceData". If extra indirection is needed it's trivial to do so at creation time. Zero filters have benefited from the extra indirection so far.

The "void **frameData" argument in VSFilterGetFrame should be changed to void *[4] to make it trivial to store a pointer (to a node usually) and an offset without allocation. Will improve splice getframe performance when a temporary allocation is no longer needed (or a complex recalculation of decisions).

Require filters to set a flag to receive arFrameReady events.

Allow a function to declare that it accepts everything and leave the handling to it
Allow a function to declare that it can return anything

Fix the weird cm prefix of colorfamily, should obviously be cf.

Remove ycocg as a colorfamily. Nobody uses it and it belongs to the YUV family anyway

registerFunction should return success or failure (function already exists, uses invalid identifier or other problem)

Review plugin loading in general. The current model makes changes extremely hard with the few things passed to registerFunction.

callFunc(VSFuncRef *func, const VSMap *in, VSMap *out, VSCore *core, const VSAPI *vsapi) should be callFunc(VSFuncRef *func, const VSMap *in, VSMap *out)

Stride should be ptrdiff_t. All other types in the API should be reviewed as well?

createFilter and filterInit overlap a lot. This means that filterInit usually ends up only setting videoinfo and nothing else. Allow videoinfo to be passed to createFilter instead and save some boilerplate code.

readOnly in configPlugin should be renamed to flags and formalized.

Prefix all functions in vshelper4.h with vsh_ or something similar for C. Maybe add a vsh namespace for C++ mode

Rename vs_normalizeRational to vs_reduceRational to make more sense

Enumerating all plugins and their ids/namespaces/whatever is kinda messy. Improve it.

queryCompletedFrame is half-broken. Fix it.

Remove getFormat and friends. Replace with a simple int that codes all the relevant data. Do the same for audio.

.propGetInt/Float should have a version to get a saturated int or float instead of only int64_t or double as the returned type. Will save plugins writers a lot casting without losing the internal representation.

Type hint for binary/utf8 for the vsmap data type make inspection filters behave better and not print junk.

Fix the vsscript api so it actually makes sense.

Add some way to set core creation flags from python and vsscript.

Change the vsscript api to export a single struct with function pointers as well.

Plugin return type hints

#601 Plugin version API

Remove compat formats since mvtools is now fully native.

Add map* functions that consume references

cloneFrame/Node/FunctionRef should be renamed to addFrame/Node/FunctionRef

Drop Ref from VSFrameRef, VSNodeRef and VSFunctionRef since it's pointless indirection

Remove multiple output nodes support completely even for api3 to reduce complexity more

Ideas skipped this time:
Filters cannot simply yield their execution time and return to the end of the execution queue. This could be useful for filters that transfer to/from GPU memory. This feature may not be added or be saved for a later API revision. Or should filters simply be able to reserve/release execution threads like is done internally already?
Support for passing frames stored in OpenCL memory
Tiling/line based filters for more effective cache usage

Also kinda depends on #508

RemoveGrain is used by a lot of popular Avisynth scripts so it would be useful to have a VapourSynth version of at least the popular modes.

There are already a few modes reimplemented in dither tools which are free to borrow and use as a starting point:
http://forum.doom9.org/showthread.php?p=1386559#post1386559

It would be good to cover most arguments for internal filters to see that the right values are accepted/rejected.

In order of importance:
Expr needs to combine constants.
FlipHorizontal/Turn180 probably should be optimized.

When both of an operator's operands are (recursively) constants, we should compute the result value ahead of time.

It seems that accept_lowercase=True only affect function name for now. Ideally arguments should benefit from accept_lowercase=True as well.

When n clips are spliced together they will usually have n cache instances as well. The best solution would be if splice could convert all caches attached to the input clips into one cache inserted after the splice.
Maybe some kind of graph inspection/manipulation should be added to the api to help with the transform.

In 36793c6 the ability to optionally change the working directory to the script's directory prior to its evaluation was added to vsscript_evaluateScript. This allows the use of paths relative to the script location. I have two issues with the current state:

• The description in VSScript.h seems to suggest that the indicated default behavior is to not change the directory while is actually the other way around. Any application should set this flag unless it has its own reasons to not to. Otherwise the users won't be able to rely on this feature.
• It would make sense to restore the original working directory after evaluating the script (is this the reason why the flag is not set for vsvfw?).

This simple script dies straight away with "No frame returned at the end of processing by StackHorizontal" (regardless of thread count):

import vapoursynth as vs

c = vs.get_core()

one = c.std.BlankClip()
two = c.std.BlankClip()

ret = c.std.StackHorizontal([one, two])

ret.set_output()

Same thing with Expr([one, two], "x y + 2 /"), but Interleave([one, two]) works...

Replacing the second clip with the first clip ([one, one]) trips an assert instead of that error:

ASSERT: "mainContext->numFrameRequests >= 0" in file ../src/core/vsthreadpool.cpp, line 162

All this happens with the latest revision, d8bdc22, but also with d1cc089.

At least use the features supported by VS2013. Possibly some C99 will be sprinkled in there as well.
Note that C++11 far from implements all used parts of Qt.

Some day when it's ready...

Make a central place to host and list all plugins and scripts to prevent doom9 treasure hunts.

Must have features:
List all plugins with a 1-2 sentence description
Have both source and windows binaries
Have maybe 3 additional links (website, doom9 thread, source code place)

Useful:
Allow plugin writers to update their own files

What happens is that vapoursynth dies with "No frame returned at the end of processing by $filter". $filter changes randomly between crashes.

This test program should make it crash pretty fast: https://gist.github.com/dubhater/6560627 It's not necessary to request frames n and n+1 over and over like that, but it seems to make the crash happen sooner/more reliably. The filters used don't seem to matter: it crashes the same with blankclip+flipvertical, or d2vsource+applyrff.

Everything is fine with 1 thread. (I think QThread::idealThreadCount() returns 2 here.)

The same happens when running a simple script through vsvpipe, though it takes longer to crash.

Before the commit 987d295 it was crashing less frequently.

The biggest feature still missing in VIVTC that TIVTC has got is override file support.

For example a wrapper class so filters can be created in a more avisynth-like way
Or smart pointers suited to the current structure

Try with a very fast script, such as one giving 1000+ fps in avisynth.