vsFilterScript: writing C++ plugins like python scripts (WIP)

[feisty2]

new functionality: full integration of C++ exceptions. with exceptions, you no longer have to manually handle any of the following errors:
a) failing to invoke an external plugin (plugin does not exist)
b) failing to invoke an external filter
c) failing to invoke a python function
d) failing to invoke SelfInvoker
... and possibly many more. SelfInvoker is now allowed to throw exceptions so the earlier restriction requiring SelfInvoker to always be successfully evaluated has been removed. Any of these errors will transparently pass through your filters and propagate to a root caller like Create() which automatically handles any error.
To you, it would be like the error does not exist so you NEVER have to worry about errors. It's now one step closer to python scripts.

Initialize() has been replaced by normal constructors because with exceptions, it is no longer required to return a value to introspect if the filter has been successfully constructed.

[feisty2]

I have nearly finished rewriting this whole thing for API v4, and I'd like to do a survey
does any one of you, including anyone that uses the vaporsynth API in external applications, use the following functions?

createCore/freeCore (implemented)
addMessageHandler/removeMessageHandler (implemented)
getFrameAsync (implemented)
createFunc (implemented)
queryCompletedFrame (deprecated)
releaseFrameEarly (deprecated)

[Myrsloik]

Originally Posted by feisty2

I have nearly finished rewriting this whole thing for API v4, and I'd like to do a survey
does any one of you, including anyone that uses the vaporsynth API in external applications, uses the following functions?

createCore/freeCore
addMessageHandler/removeMessageHandler
getFrameAsync
createFunc
queryCompletedFrame
releaseFrameEarly

createFunc/createCore/freeCore - will be used in applications that manually build graphs
addMessageHandler/removeMessageHandler - vspipe/vsedit/just about all consumers of vsscript will be using it
getFrameAsync - vspipe/vsedit/just about all applications retrieving frames
queryCompletedFrame - deprecated and 0 known uses in the wild
releaseFrameEarly - 0 known uses

[feisty2]

I have implemented the wrapper for createFunc() in the form of Core.Mount(), but I'm not sure if the implementation is correct because this function is rarely used and certain cython functions relating to it seem "fishy". you're welcome to examine the code of Core.Mount or play with it if you're familiar with createFunc().

Core.Mount() could be used to mount any callable entity (function, function pointer, lambda expression, or any type that overloads operator()) compatible with any of the following signatures:

auto()
auto(auto Arguments)
auto(auto Arguments, auto Core)
// the return value may be of any type supported by VSMap, or an iterable container of any type supported by VSMap, or void

into the VS core, and the mounted function could be called in any context. for instance, you may mount a C++ function and assign the mount point to a frame property, and call the mounted function in a vpy script. the following example works as expected.

// C++ code, inside getFrame()
auto f = [](auto args) {
	auto msg = static_cast<std::string>(args["msg"]);
	vsapi->logMessage(VSMessageType::mtWarning, msg.data());
	throw RuntimeError{ "hello world" };
};
ProcessedFrame["test"] = Core.Mount(f);


#Python script
clip = core.test.Test(clip)
clip.get_frame(0).props['test'](msg = 'aaaaa') # prints 'aaaaa', then prints 'hello world' in the error message.

you cannot currently mount non-void functions even though this functionality has been implemented, because:
a) the cython function Func.__call__ does not seem to handle the return value of the mounted function properly, the return value seems to be discarded in the process.
b) the type deduction required by Core.Mount() is so complex that it actually crashes GCC10 if you specify a non-void function to it (internal compiler error: in cp_get_fndecl_from_callee, at cp/cvt.c:1000). I'll see if this problem has been fixed in GCC11 and file a bug report if not.

[feisty2]

I updated my toolchain and the compiler bug mentioned above has been fixed in GCC trunk. I did some quick tests and Core.Mount() properly mounts any supported function-like entity, with a void or non-void return value. Any mounted function can be properly invoked in C++ programs, however you still cannot call non-void mounted functions in python and that's something only @Myrsloik can fix. The corresponding cython code has been broken since 2014 and still hasn't been fixed.

[Myrsloik]

Originally Posted by feisty2

I updated my toolchain and the compiler bug mentioned above has been fixed in GCC trunk. I did some quick tests and Core.Mount() properly mounts any supported function-like entity, with a void or non-void return value. Any mounted function can be properly invoked in C++ programs, however you still cannot call non-void mounted functions in python and that's something only @Myrsloik can fix. The corresponding cython code has been broken since 2014 and still hasn't been fixed.

YES! Your software is at my mercy! MUAHAHAHA

[feisty2]

well, I don't really have a problem with this thing being partially broken since it's rarely used anyways...
I simply wanna do some tests to verify if my implementation is correct. I'll just move on to the next function in line if there's no plan to fix this any time soon

[feisty2]

I have implemented getFrameAsync() as Node::ExpectFrame(). This is yet another function that I'm not 100% sure if I have implemented correctly since I don't have a standalone VS application like vsedit to test it. Based on my quick (and evil) test which invokes this thing inside a filter's constructor, it seems to work properly. After reading the internal code of getFrame()/getFrameAsync(), I realized it's actually a lot simpler than I originally thought. I don't need to mess with threads and locks, getFrameAsync() already renders the frame in a new thread and I simply need to return a future and fulfill the promise inside the callback.

a call to Node::ExpectFrame() instantly starts rendering the requested frame in a new thread and returns a future that lets you retrieve the frame some time later when needed.

auto f = Clip.ExpectFrame(n); // instantly start rendering frame n in a new thread
... // do something else while waiting for the rendering completes
auto frame = f.get(); // now retrieve frame n, if the rendering hasn't finished yet, block the current thread until the frame is available and retrieved.

[feisty2]

I have finally implemented support for custom message loggers by year 2021
the mutex thing really got me good...

you may send a message to all registered loggers by calling Core.DebugPrint/Print/Alert/CriticalAlert/Abort(Message), or send a message to a particular logger x by calling x.DebugPrint/Print/Alert/CriticalAlert/Abort(Message)

Core.TetherLogger() tethers a logger function to VS and returns a corresponding logger object. the logger function may be any callable entity compatible with any of the following signatures:

auto(auto Message)
auto(auto MessageType, auto Message)

"MessageType" may be of type auto/MessageTypes/VSMessageType/int, auto assumes MessageTypes
"Message" may be of type auto/const char*/std::string_view, std::string or anything constructible from const char*, auto assumes std::string_view

the logger object is reference counted and the corresponding logger function will be automatically removed from VS when the reference count drops to 0. alternatively, you may call logger x's member function x.Untether() to remove its corresponding logger function early, or x.Detach() to release the ownership of its corresponding logger function. The detached logger function will be permanently installed into VS and is removed only when the VS process terminates (API v3) or when the core is freed (API v4). you may directly add a permanent logger by calling Core.InstallLogger() which is equivalent to TetherLogger().Detach()

[feisty2]

soon this thing will have 100% coverage of the C API, once I fill in the last missing piece of the puzzle (createCore/freeCore)
yay!

[feisty2]

100% coverage (excluding 2 deprecated functions) of the C API achieved! finally!

[feisty2]

@Are_
could you run a speed test for GaussBlur and GaussBlurFast again? I applied more optimizations, mostly tags for more aggressive inlining and less indirection (so probably less cache miss)

[Are_]

Ran them three times and seemed consistent.

Old GaussBlur:
Output 100000 frames in 27.22 seconds (3674.02 fps)
Old GaussBlurFast:
Output 100000 frames in 5.92 seconds (16891.87 fps)
New GaussBlur:
Output 100000 frames in 31.10 seconds (3215.69 fps)
New GaussBlurFast:
Output 100000 frames in 5.90 seconds (16959.92 fps)

[feisty2]

it just occurred to me that I actually changed the default padding function to "reflect" in the current version, it's a bit slower but better preserves the structure of the image, and thus GaussBlur also got a bit slower. however GaussBlurFast was not affected by such change and it is indeed now a bit faster, that's enough to prove that the optimizations do work as expected :-)

[vcmohan]

The filter skeleton generator link does not exist. Get 404 error.

[lansing]

Just curious, will this works with making filter loader plugins like Vdubfilter? I tried with C API but got lost really quick.

[feisty2]

Originally Posted by vcmohan

The filter skeleton generator link does not exist. Get 404 error.

it is recommended to use the stable branch for now, you can find the skeleton generator here: https://github.com/IFeelBloated/vsFi.../Interface.vxx

[feisty2]

Originally Posted by lansing

Just curious, will this works with making filter loader plugins like Vdubfilter? I tried with C API but got lost really quick.

something like std.LoadPlugin? presumably yes, I can write an example if necessary

[lansing]

Originally Posted by feisty2

something like std.LoadPlugin? presumably yes, I can write an example if necessary

Like avs.LoadPlugin

[feisty2]

this thing is now feature complete and I renamed it vapoursynth++

things left to do:
code cleanup
documentation
replace header files with C++ modules