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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
