Vapoursynth

[Myrsloik]

Originally Posted by feisty2

is the message handler attached to each core and no longer global in API v4?

Correct

[feisty2]

what's the use of removeMessageHandler()? it seems I can remove the current handler by simply passing a NULL handler to addMessageHandler()?
who owns the char pointer that the handler receives? is it the same pointer passed to logMessage() or a pointer to some internal deep copy of what's passed to logMessage()?

[Myrsloik]

Originally Posted by feisty2

what's the use of removeMessageHandler()? it seems I can remove the current handler by simply passing a NULL handler to addMessageHandler()?
who owns the char pointer that the handler receives? is it the same pointer passed to logMessage() or a pointer to some internal deep copy of what's passed to logMessage()?

addMessageHandler() simply adds one more handler, it never removes the current one
you then remove the handler by passing the handle from addMessageHandler() to removeMessageHandler()
Ownership is also optional since all handlers obviously will be removed automatically when a core is destroyed. Calling removeMessageHandler() with an invalid/already freed handle is safe and does nothing.

[feisty2]

interesting, I didn't realize there could be multiple message handlers. so logMessage() will send the message to all registered handlers?

[Myrsloik]

Originally Posted by feisty2

interesting, I didn't realize there could be multiple message handlers. so logMessage() will send the message to all registered handlers?

Yes

Filler here

[feisty2]

I can't decide which is the correct design for message handlers.
should I bind the lifetime of a message handler to its descriptor, like a file descriptor?

auto md = Core.AddMessageHandler([](auto...) {});
// md is a stateful object
// automatically calls removeMessageHandler() in md's destructor when it goes out of scope

or should I let the user manage the handler's lifetime manually?

auto md = Core.AddMessageHandler([](auto...) {});
// md is a stateless integer ID / pointer

Core.Eject(md);
// explicitly ejects the handler when no longer needed.

[feisty2]

does getFrameAsync() have any special behavior (creating new threads, etc.)?
it seems the same asynchronous behavior could be achieved by simply calling getFrame() with std::async?

auto f = std::async(std::launch::async, [&] { return vsapi->getFrame(n, node, nullptr, 0); });

... // do something else while waiting for f

auto frame = f.get(); // block the current thread and retrieve the frame when needed

why should I use getFrameAsync() instead of something like the code above?

[Selur]

I use a jpeg as source:

General
Complete name                            : c:\Users\Selur\Desktop\test.jpg
Format                                   : JPEG
File size                                : 465 KiB

Image
Format                                   : JPEG
Width                                    : 1 280 pixels
Height                                   : 534 pixels
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Compression mode                         : Lossy
Stream size                              : 465 KiB (100%)

which I open using:

clip = core.imwri.Read(["C:/Users/Selur/Desktop/test.jpg"])
clip = core.std.Loop(clip=clip, times=100)

what confuses me is that the file is reported as RGB24.
Does ImageMagick Writer-Reader (http://www.vapoursynth.com/doc/plugins/imwri.html) always return RGB or am I missing something?
In case it always returns RGB, it would be nice if this could be added to the documentation.

Cu Selur

[Myrsloik]

Originally Posted by Selur

I use a jpeg as source:

General
Complete name                            : c:\Users\Selur\Desktop\test.jpg
Format                                   : JPEG
File size                                : 465 KiB

Image
Format                                   : JPEG
Width                                    : 1 280 pixels
Height                                   : 534 pixels
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Compression mode                         : Lossy
Stream size                              : 465 KiB (100%)

which I open using:

clip = core.imwri.Read(["C:/Users/Selur/Desktop/test.jpg"])
clip = core.std.Loop(clip=clip, times=100)

what confuses me is that the file is reported as RGB24.
Does ImageMagick Writer-Reader (http://www.vapoursynth.com/doc/plugins/imwri.html) always return RGB or am I missing something?
In case it always returns RGB, it would be nice if this could be added to the documentation.

Cu Selur

It probably always returns RGB... maybe.

[feisty2]

some elaboration on the issue mention at #4187 would be nice...
it's hard to determine the design of the async interface without knowing the technical details of the C API. also it's a lot harder to convert a callback kind of stuff to std::future which involves locks, condition variable and other unnecessary complexity.

[Myrsloik]

Originally Posted by feisty2

some elaboration on the issue mention at #4187 would be nice...
it's hard to determine the design of the async interface without knowing the technical details of the C API. also it's a lot harder to convert a callback kind of stuff to std::future which involves locks, condition variable and other unnecessary complexity.

Internally getFrame() is implemented as a function that waits for getFrameAsync() to return. So I guess wrapping getFrame() in a future would be close at least. But with a lot of unnecessary locking and bookkeeping added.

[feisty2]

I think "id" should be a member of VSVideoFormat in API v4, otherwise it requires access to the core to determine if a clip has a constant format which is not very convenient

[feisty2]

or at least make the core parameter optional for queryVideoFormatID()

[feisty2]

it seems API v4 uses the colorfamily to determine if a format is constant, that's a bit weird...

[Selur]

Is there an "autowhite" filter which is more clever than the example over at http://www.vapoursynth.com/doc/functions/frameeval.html ?

[feisty2]

What do you mean by "more clever"? Like adding temporal consistency?

[Selur]

Yes, exactly. Temporal temporal consistency while taking scene changes into account. I was looking for some 'auto' filters like AutoAdjust, AutoContrast, Autolevels, HDRAGC and similar for Vapoursynth and the frameeval example of autowhite was the only thing I found. Seeing that it was a 'simple per frame auto white balance', I was wondering if there are mor complex/clever solutions out there.

[feisty2]

Originally Posted by Selur

Yes, exactly. Temporal temporal consistency while taking scene changes into account. I was looking for some 'auto' filters like AutoAdjust, AutoContrast, Autolevels, HDRAGC and similar for Vapoursynth and the frameeval example of autowhite was the only thing I found. Seeing that it was a 'simple per frame auto white balance', I was wondering if there are mor complex/clever solutions out there.

here: https://github.com/IFeelBloated/Auto...master/src.cxx, basically the same as that FrameEval stuff, but with temporal functionalities. writing vaporsynth filters is really easy, it's really no different from scripting in Python. you should consider writing a filter yourself next time you wanna add some basic extensions to an existing script/plugin.

[Selur]

Nice. Thanks!

[Myrsloik]

Originally Posted by feisty2

I think "id" should be a member of VSVideoFormat in API v4, otherwise it requires access to the core to determine if a clip has a constant format which is not very convenient

Only id = 0 mean variable format. This is strictly enforced by all the api functions. The reason the api function need the core pointer is to maintain V3 api compatibility where the id isn't a simple serialization so a V4 filter won't choke if it's fed a V3 id.
If it truly bothers you look at the macro used to create ids and parse them on your own, the only advantage the api gives you is that invalid combinations will be rejected instead of possibly passed on.