[FFmpeg-devel] [PATCH] lavfi/af_anequalizer: remove cabs, cexp dependencies

Matt Oliver protogonoi at gmail.com
Wed Dec 30 05:32:49 CET 2015


On 30 December 2015 at 03:15, Ganesh Ajjanagadde <gajjanag at mit.edu> wrote:

> On Mon, Dec 28, 2015 at 10:27 PM, Matt Oliver <protogonoi at gmail.com>
> wrote:
> > On 29 December 2015 at 11:51, Ganesh Ajjanagadde <gajjanagadde at gmail.com
> >
> > wrote:
> >
> >> On Mon, Dec 28, 2015 at 8:22 AM, Paul B Mahol <onemda at gmail.com> wrote:
> >> > On 12/27/15, Ganesh Ajjanagadde <gajjanagadde at gmail.com> wrote:
> >> >> Replaces by real arithmetic. Tested the validity of these
> >> transformations
> >> >> separately.
> >> >>
> >> >> Signed-off-by: Ganesh Ajjanagadde <gajjanagadde at gmail.com>
> >> >> ---
> >> >>  configure                    |  1 -
> >> >>  libavfilter/af_anequalizer.c | 25 +++++++++++++++++--------
> >> >>  2 files changed, 17 insertions(+), 9 deletions(-)
> >> >>
> >> >
> >> > If those are mathematically equivalent ok.
> >>
> >> mathematically equivalent, tested offline, numerical differences of
> >> the order of ~ 1e-15 or so, which is perfectly fine IMHO for double
> >> precision especially since it is a priori not clear which is more
> >> precise. Pushed, thanks.
> >
> >
> > Wouldn't it also be a good idea to remove the COMPLEX_FUNCS list from
> > configure as now neither cabs or cexp are used so configure can be
> > simplified by removing the checks for them.
>
> I asked Paul about this (when I removed them from some other filter).
> That time he said he wanted them for another filter (anequalizer)
> since the expressions were complicated. Judging from this commit, I
> think that was a fair assessment.
>
> In short, this is really a question for Paul (or others who use
> complex numbers): if there are plans on doing something with complex
> numbers that is not trivial to rewrite, it may be helpful not to
> remove as you suggest. If not, then it is perhaps ok.
>
> Personally, over the long term, I think there will be further
> instances of complex number usage. If we remove it now, I suspect it
> will get added back in at some point. As such, I won't write a patch
> for this; really upto others especially Paul.
>
> Maybe long run we can create an av_complex or something like that. A
> few problems are (among possibly many others):
> 1. Syntactic sugar for *, / , +, - will be lost, and one will need to
> create something like cmult, cdiv, and call at an increased verbosity
> cost. In C++, these basic operators can be overloaded (but then again
> stdc++ has a complex header); AFAIK there is no such mechanism that we
> can use in FFmpeg's "least common denominator" C.
> 2. Natural promotion rules will be lost, e.g suppose one passes a
> double to a complex function, say while multiplying a double complex
> by a double as in anequalizer. With proper complex number support,
> promotion rules kick in and everything works. With av_complex, this
> does not work, and explicit setting of imaginary part to 0 will be
> needed.


Fair enough, I was just checking.


More information about the ffmpeg-devel mailing list