[FFmpeg-devel] [PATCH] lavfi/volume: add dynamic expression evaluation

[Clément Bœsch]

On Tue, Mar 05, 2013 at 10:51:33PM +0100, Stefano Sabatini wrote:
> On date Tuesday 2013-03-05 18:10:45 +0100, Stefano Sabatini encoded:
> > On date Tuesday 2013-03-05 16:08:54 +0100, Nicolas George encoded:
> > > Le quartidi 14 ventôse, an CCXXI, Stefano Sabatini a écrit :
> > > > That's a solution (or add a filter variant). The other solution would
> > > > be to make the filter behaves in a different way if the expression is
> > > > constant (CONST OP CONST is detected as constant), which would need
> > > > some hack to the eval code (of course this can't detect things like
> > > > EXPR-EXPR).
> > > 
> > > Detecting what variables / functions are used in the expression is not
> > > impossible at all, and it would allow to know whether the expression is
> > > constant or not even in complex cases.
> > > 
> > > > Please tell what you prefer (and feel free to pick the patch and
> > > > improve it yourself if you're in hurry).
> > > 
> > > Could you make a quick benchmark, using a small frame size (asetnsamples=16
> > > for example): that would greatly help knowing whether it is worth optimizing
> > > that or not.
> > 
> > I'm trying to implement av_expr_is_const() (and trying to clean up
> > eval code a bit at the same time).
> 
> And here there is a problem. In case I have something like this:
> foo(100);
> 
> assuming the function is constant (and there is no way to know in case
> it is an user function), then the evaluation is obviously constant.
> 
> OTOH if we have:
> foo(W+X)
> 
> we don't know which parameters we assume are going to change (which
> really depends on the implementation, if the parameters are reset
> after one evaluation and the next one).
> 
> So av_expr_is_const() doesn't seem like a viable choice (unless I'm
> missing something), because it helps only in a few trivial cases,
> when no custom functions and no variables are used in the expression.
> 

Having a av_expr_is_const() not very efficient (aka returning "it's not
const" even when it actually is) is not really a problem. The main thing
we are interested in is to not slow down the obvious cases such as
volume=-3dB. When the user starts to use expressions, there might be a
risk of slow down, but that's not really problematic in most cases IMO.

Everytime custom functions or custom var_values are used, just return 0.

You should be able to detect the usage of the eval local/general constants
and builtin constant functions to detect as const stuff like sin(3*PI).
That's in my opinion more than enough for a first version since it will
prevent ANY slowdown with what the users are currently doing.

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130305/9aa1f8f9/attachment.asc>