Simple Runtime Function

[StainlessS]

Originally Posted by TheFluff

Slightly academic, but this can overflow with very large frames (slightly bigger than 4096x4096). If you want a 64-bit integer with MSVC in 32-bit mode use __int64 (or #include <stdint.h> and use int64_t). sizeof(long) is 4 in pretty much all 32-bit compilers.

OK, you win, implemented 64 bit accumulator.

[TheFluff]

Originally Posted by StainlessS

EDIT: I'll look at the "YUV-to-RGB conversion", thanks,
but dont look hopeful as would require invoke on every frame (runtime filters dont have constructors), from the link you posted:

Avisynth supplies you with the user_data pointer for a reason, stick the clip generated by the env->Invoke() call there. Of course, then you run into problems if your function is called multiple times in the same script but with different clips... Solving those problems is left as an exercise to the reader.

[StainlessS]

Originally Posted by TheFluff

Avisynth supplies you with the user_data pointer for a reason, stick the clip generated by the env->Invoke() call there. Of course, then you run into problems if your function is called multiple times in the same script but with different clips... Solving those problems is left as an exercise to the reader.

Originally Posted by StainlessS

EDIT: The user always has the option of convert to eg Y8 or YV12 before calling the runtime filter, that would be best all round.

Thanks, think I'll stick with that. It is expected (the way I expect to use it) that args would change, having a fallback if user does not convert to a YUV form is not such a bad thing.

Originally Posted by TheFluff

Solving those problems is left as an exercise to the reader.

I have not seen any explanation of how the user_data thing works (other than in the font thing using a malloc string,
no idea how it would fare with Avisynth objects and/or whether they would need destroyed).
Also, thanks but I dont need any exercises, quite happy living in ignorance and if you knew how to
solve the "problem", you would no doubt have said so.

[TheFluff]

Why do you even want to support RGB input to a function that is only meaningful for YUV images?

Originally Posted by StainlessS

I have not seen any explanation of how the user_data thing works (other than in the font thing using a malloc string,
no idea how it would fare with Avisynth objects and/or whether they would need destroyed).

user_data is void* pointer. That means it can point to anything. That means you can create an arbitrary object or c struct or whatever floats your boat, get a pointer to it and set user_data to that pointer. The environment will pass the pointer back to you each time your function is called, thus neatly solving the problem with arbitrary functions that need to keep some kind of state between calls, without having to resort to ugly hacks like global static objects.

In other words: create some kind of object or struct that stores any state you want to save. Do this in AvisynthPluginInit2, and pass a pointer to the object in question as the last argument to env->AddFunction. This pointer will be passed to the function you just registered, as the user_data argument. Do whatever you want with the object there. If you're worried about memory leaks, register an env->AtExit() hook that deletes the object.

The PClip class acts as a reference counted smart pointer; it behaves much like its relatives in the C++ standard library does and has the same semantics. If you're not familiar with how smart pointers work in C++, I really think you should take the time to read up on it.

Originally Posted by StainlessS

Also, thanks but I dont need any exercises, quite happy living in ignorance and if you knew how to
solve the "problem", you would no doubt have said so.

I didn't explain it because it's a tedious problem to solve, not a hard one. You just need to make your code handle an arbitrary number of clips, not just one, and find some way of identifying which clip you're currently working with.

[StainlessS]

Originally Posted by TheFluff

Why do you even want to support RGB input to a function that is only meaningful for YUV images?

Fallback.