Per frame conditional filtering one, understand, reference, version

andy

Continued from this thread.

Originally posted by WarpEnterprises
2) I still don't understand why you use three parameters instead of one string evaluating to a bool. It would be much clearer to script writers.Adding a second version that only takes one string later is not a big deal. Right now this was the easiest way to control it.

4) what does that mean:   when you reference a video clip ... it will be represented by the value it has at the end of the script?  Putting a clip in the condition function feeds not the current value but the last in the script? That means it is strongly suggested to only use implicit last as this is how you feed the testclip?

That means, if you use variables in the condition tests, you may not redefine any of them later in the script.
The condition checks are run after the entire script has been parsed, and the graph has been created. Therefore any variables that has changed since the condition filter will contain their new values. An example:

vid=last.blur(1.5)
Conditionalfilter(last,last,last,quot;LumaDifference(vid)quot;,quot;=quot;,quot;0quot;)
vid = avisource(quot;hest.aviquot;)

The lumaDifference will be calculated to the AVISource vid clip.
Unfortunately I cannot see any way to avoid this.

ad. 5). Yes - it is checked, just as colorspace, etc. (I may have missed a few in the exitement though).
ad. 6-9) Yes - User defined Filtering based on image properties opens up many possibilities.

Originally posted by sh0dan
That means, if you use variables in the condition tests, you may not redefine any of them later in the script.
The condition checks are run after the entire script has been parsed, and the graph has been created. Therefore any variables that has changed since the condition filter will contain their new values. An example:

vid=last.blur(1.5)
Conditionalfilter(last,last,last,quot;LumaDifference(vid)quot;,quot;=quot;,quot;0quot;)
vid = avisource(quot;hest.aviquot;)

The lumaDifference will be calculated to the AVISource vid clip.
Unfortunately I cannot see any way to avoid this.

Since it evaluates at the end of the script, it could be good for defining script profiles.  It could be good if we could make some sort of compressibility evaluation within a script  for example.
Would this be somewhat possible?

@hakko504
That would need frame-by-frame evaluation for conditional filtering,
some sort of a WHILE function, sh0dan has already made a feature request for 3.0 (mentioned in this thread )

Best regards,
Bilu

Originally posted by bilu @hakko504
That would need frame-by-frame evaluation for conditional filtering,
some sort of a WHILE function, sh0dan has already made a feature request for 3.0 (mentioned in this thread )
I thought frame-by-frame evaluation was the whole point of this filter, and why on earth would it require a WHILE loop?  If you just look at 2 frames, one containing a lot of interlacing effects, the other doesn't, then you should return the one with the least interlacing. There is nothing in this that would require looking at an old frame.

You're right, frame-by-frame evaluation of frames, variables, etc. is needed for a WHILE function, but it's more than just that.

Anyway, it seems that frame-by-frame evaluation can't be done until 3.0 at least.

Bilu

Originally posted by WarpEnterprises
2) I still don't understand why you use three parameters instead of one string evaluating to a bool. It would be much clearer to script writers.

Adding a second version that only takes one string later is not a big deal. Right now this was the easiest way to control it.

That was my point in the other thread. Was I so cryptic you didn't understood me ?In a perfect world, it will use actual arg values and not the final ones.
I have a proposal to make it possible : use placeholders in the string and pass their values as addditional parameters :

example:
...
vid=last.blur(1.5)
Conditionalfilter(last, last, last, quot;LumaDifference(_vid_) == 0quot;, vid)
vid = avisource(quot;hest.aviquot;)

_vid_ is a placeholder, when evaluating the expression, it has to be setup to a specified value.
In this case, the clip vid.

Since values to be used are passed as additional params, it's their actual values who are used.

before going farther into this per-frame-filtering maybe we should discuss a framework (how such functions should look like, what should be possible and what not, features such as the parameter passing,...)

I have another two ideas:

- printing the CURRENT time on the video (per-frame-call of Subtitle(Time(quot;...quot;))

- passing of some kind of spline to generate coordinates (e.g. to move a logo or mask around) instead of writing long expressions: has anyone some experience in this field? What GUIs could be used to create these? I imagine viewing a video and moving a cross around, at the same time mapping the coordinates of the cross and generating a spline that can be passed to our per-frame-functions

Maybe by allowing frames to be a type. (accessible or not in scripts ?)
Then we can have functions who work with them and your subtitle(time) is no big deal.

For splines I don't know, probably an additional types too.

thought a bit and frames better be accessibles in scripts that's the easier way.

Imagine something like it :Code:
source = avisource(quot;myclip.avi)

result = voidClip(source)  //mean it has 0 frames but same others params

for (i = 0; i lt; source.framecount; i++)
{ frame = source[i] //do something to frame result.append(frame)
}
return result
Would be nice, no ?

In the other hand, that would make a really huge filter graph :/

Code:
result = Transform(source, frame_to_frame_function)
Then.

@Bidoche: We might very fast run into problems with the stack size. As you can see in this bug submission it is already possible to overload the stack using conventional scripts. A real (C-style) quot;forquot; or quot;whilequot; loop will most likely trigger this problem even easier, as you point out yourself.

Besides that the excessive filter number would most likely also pose a memorywise problem, if they all allocate (even minor) temporary buffers.

/me as always being the pessimist  

@WarpEnterprises: A nice idea actually - even though it might as well be put into a filter. There could however be made a filter that returned the frame from a script that could be dynamically updated. Then a given set of variables could be created that would be updated each frame before creating the filters.

ScriptClip(source, quot;Subtitle(SC_CurrentSample)quot;)

Where quot;sourcequot; would be used for implicit last, and quot;SC_currentsamplequot; is updated each frame.  Boy this is actually easy.
The problem is still where the videoinfo information should come from - the best solution would be to request a frame from the script, and extract videoinfo from that one. Makes good enough sense actually.

Maybe we can have the parser transform the 'for...' structure into a filter call with a parameter frame function...
With some restrictions, it may be possible.

Need some more thought.

1) I found a way to write a script function Spline (put it in my CHR.DLL - maybe it's worth to include it together with Chr and Time in the core?)

2) After thinking over the new blend of per-frame-filters there are some other (internal) filters that would be quite funny to have with frame-variable parameters:

Letterbox: simulate a quot;curtainquot; fade out
Tweak, Levels: generic Fade or trick filters
MergeChroma / MergeLuma: a generic dissolve

It would be similar to Animate but allowing arbitrary functions and without calling the filter construct n-times and eating up memory.

Would this have any support?

The most generic way to implment them would probably be as specific interpolation functions.

float LinearInterpolate(float from_value, float to_value, float position) {position = max(min(1.0,position),0.0f)return from_value + (position * (to_value - from_value));
}
The actual float then being returned as AVSValue, just as you did in chr. Similar for BSpline, Sine - and all similar interpolators you can think of.

Then you would be able to use it in something like ScriptClip for all functions. Of course invoking a new filter on each frame (as Animate) is not optimal, but it would allow for the interpolators to be used everywhere.

A major gain in a redesign could be if it was possible to define any parameter as a variable that would be updated each frame (like proposed in ScriptClip, and implemented in ConditionalFilter). This would unfortunately mean a redesign of the current API, and the way filters are handled.  
Something like - each filter defines the variables available, and puts them in a place accessible to AviSynth, where it can update there settings before the filter is run.  This would lead to an immense amount of flexibility, at little performance cost, but with a massive (re-)programming requirement.

It would fit nicely into the goal Bidoche has created for externalizing parameters, and making them more accessible for external applicartions.  However - we need a larger core crew to be able to implement something like this in a forseeable future.  90% of all filters would need some form of rewriting - some even more than the rewrite for YV12.

The only quot;non-flexiblequot; thing would then be image sizes, colorspaces, etc. which IMO still would have to remain static. The idea of changing that is appealing, but the consequences in terms of programming are beyond what I see possible.
Btw, getting:

404 Not Found
The requested ucl /~warpenterprises/files/chr_25_dll_200300404.zip was not found on this server.

link corrected.