Filter feedback

[High Speed Dubb]

Here’s a small AVISynth programming question...

If I understand right, GetFrame(n, env) for a negative n returns Frame n before it was processed by that filter.

Is it possible to ask for Frame n after it has been processed, instead? That would be handy for filters which use feedback (such as a denoise filter). Or should the filter just save a copy of its previous output?

[sh0dan]

GetFrame(n, env) returns frame n
GetFrame(n-1, env) returns frame n-1 (previous frame)
GetFrame(n+1, env) returns frame n+1 (next frame)

If your were to request n+1 when it was processed, that filter would request n+1, that would make the next filter request n+1... and so on... and so on. The same with n-1, if the user has skippped ahead, used trim or similar.

So returning processed frames is not a good thing.

[High Speed Dubb]

Hmm... I’m not sure I understood that. So if a filter needs to access a previously processed frame, it’s best to make a local copy of it, rather than to request it from AVISynth?

PS: I’m requesting the frames for reading, not writing. Would the other filters still need to request that same frame again?

[sh0dan]

ok - for what do you actually need this?

It's impossible to request any frames your own filter has processed, since you will end up in a long loop. Here's why:

1) Your filter is requested to deliver frame 1000
2) You filter requests the filtered previous frame, which is not in cache.
3) Your filter therefore is requested to deliver frame 999 processed.
4) For your filter to process frame 999, it requests the filtered frame 998
5) Frame 998 isn't in cache either
6) Your filter therefore is requested to deliver frame 998 processed.
7) For your filter to process frame 998, it requests the filtered frame 997.
8) Frame 997 isn't in cache either....

... Therefore, if the user requests frame 1000, all previous 999 frames will have to be processed. They will also all have to be in memory AT THE SAME TIME (none of the 1000 frames can return before all have been processed).

This is why you cannot request frames processed by your own filters. It would become a mess!

Copying (not only storing a pointer!) the previously processed frame is a possibility, but it is not a good solution, since you cannot rely on linear access. Therefore your filter has a big risk of returning different data for the SAME frame each time it is run, which should be avoided. It would also break, if multithreading is used.

[High Speed Dubb]

It’s for a noise filter. In a stationary picture, the (noise filtered) previous frame provides a better estimate of the true color than does the unfiltered previous frame. In signal processing terms, this lets me use an IIR (infinite impulse response) filter.

Copying the previously processed frame will be slow, but it isn’t a problem for the filter — I can just check to make sure they’re really contiguous. If not, the filter can just return without processing the image at all (as would be appropriate for any temporal filter).

[sh0dan]

Copying the frame can be done quite fast and with the built in BitBlt, it'll probably only have a minimal impact on your performance.

[High Speed Dubb]

Thanks for the help, sh0dan. Hopefully it’s working correctly, now... :)