Quote:
Originally Posted by gzarkadas
I made some modifications to my script to simulate your proposed solution of setting current_frame at the end of runtime filters, by backing up its value in a chained FrameEvaluate and restoring at the end of each script block ... However, this does not work; the output is exactly (disregarding the added text) the same as the non-corrected script's.
|
You cannot fix the problem with a chained FrameEvaluate because FrameEvaluate itself has already set current_frame to the wrong value before you can get your hands on it to save it in backup2. Catch 22!
The inline re-assignment after calling AverageLuma works of course, but it is just a work-around. It could be implemented 'for real' by putting my save/restore code around the GetFrame call in every run-time
function, but this is putting the fix in the wrong place.
Quote:
|
... the runtime filter does not have the chance to properly restore the value of current_frame (which happens inside the Evaluate call), unless a hook is placed either at the parser or at the Evaluate method to analyse the chain and recognise that a situation such the one that we talk about occures and apply logic to overcome it. This solution is costly in terms of performance; the price would have to be paid at every frame.
|
What you are missing here is that the overwriting of current_frame during the evaluation only occurs inside the
other run-time filter's GetFrame call, invoked as part of that evaluation. It is there that the fix restores the original value (still inside the evaluation), which is then seen by the remainder of the evaluation.
Effectively, each run-time filter's GetFrame should leave current_frame as they found it, by far the cleanest solution.
This is still a 'per-frame' overhead, but only on
run-time filters, and very minor in comparison to the work they already have to do for every frame (parsing and evaluating the run-time script and fetching a frame from it).