[FFmpeg-devel] [PATCH] avutil/eval: add function to track variable use

[Gyan]

On 05-11-2019 07:40 pm, Nicolas George wrote:
> Gyan (12019-11-05):
>> An example of a cross-referenced expression would be 'y=x+rand(10)'.
>> Normally in filters, X would be evaluated first, then Y, then X again. The
>> 2nd eval of X will overwrite the first and can generate a different value.
>> With this func, we can avoid the 2nd eval.
>>
>> I'm in the process of modifying the scale filter to allow 'n', 't', 'pos'
>> variables in frame eval mode (it already supports dynamic output based on
>> incoming frame changes) and I would like to catch their presence in init
>> mode, since av_expr_eval will fail. Now, it can also fail due to circularly
>> referenced expressions e.g. 'x=y+10' and 'y=x+10' and there's no way to
>> detect whether it's this case or if inapplicable variables have been used.
> Then I would prefer that we wait for that to be done and working to
> commit this patch. After all, it is entirely possible that you realize
> this is not exactly what you need to achieve your goal.

I've looked for workarounds using existing API and I haven't found one. 
In my scale patch, I've implemented this function locally and it 
fulfills the role. Thought I should insert it generically.
> Also, you may consider if it would be worthwhile to globally improve the
> expression system: maybe have a context with dedicated structure to
> define the variables and custom functions instead of just arrays that
> needs to have the same size
>
> The scale filter is not the only one with multiple expression
> evaluation, it would be a waste if the simplification was not applicable
> to all cases easily.
I have come across the need for this helper in other filters like the 
various draw* filters but it was never a priority. But the changes to 
scale/scale2ref filter need it or its equivalent. This one does the 
trick and I can see how it would be helpful in animation support for 
drawbox where all vars can refer to each other, so each expression is 
evaluated 5 times. That work is half-way done and is my next focus.

> (Also, the possibility to define user variables would be nice. But that
> would require re-writing most of the parser. It needs doing anyway, but
> it is a huge work.)
That sounds desirable but that needs careful design in terms of 
sanitation of user input. That looks to be a job for another day. 
Possibly, early next year.

Thanks,
Gyan