[FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation

Muhammad Faiz mfcc64 at gmail.com
Wed Nov 4 04:52:43 CET 2015

On Tue, Nov 3, 2015 at 1:20 PM, Ganesh Ajjanagadde <gajjanag at mit.edu> wrote:
> On Tue, Nov 3, 2015 at 12:54 PM, Muhammad Faiz <mfcc64 at gmail.com> wrote:
>> On Tue, Nov 3, 2015 at 3:47 AM, Ganesh Ajjanagadde <gajjanag at mit.edu> wrote:
>>> On Tue, Nov 3, 2015 at 5:06 AM, Muhammad Faiz <mfcc64 at gmail.com> wrote:
>>>> On Sat, Oct 31, 2015 at 10:15 AM, Ganesh Ajjanagadde <gajjanag at mit.edu> wrote:
>>>>> On Fri, Oct 30, 2015 at 7:29 PM, Michael Niedermayer
>>>>> <michael at niedermayer.cc> wrote:
>>>>>> On Fri, Oct 30, 2015 at 06:53:34PM -0400, Ganesh Ajjanagadde wrote:
>>>>>>> On Fri, Oct 30, 2015 at 6:35 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
>>>>>>> > From: Michael Niedermayer <michael at niedermayer.cc>
>>>>>>> >
>>>>>>> > This should fix the build failure of avf_showcqt.c
>>>>>>> >
>>>>>>> > An alternative solution would be to add a check for fmin/fmax to fate-source and
>>>>>>> > then to replace them by FFMIN/FFMAX, i can do that if preferred?
>>>>>>> >
>>>>>>> > Untested due to lack of a affected platform
>>>>>>> I recall some interest on my end to get fmin, fmax etc for different
>>>>>>> reasons, and it was remarked that commit
>>>>>>> 4436a8f44dedc83767b3d9da9beb85d1fae2ca30 may be relevant. The summary
>>>>>>> seems to be that getting it to work on all platforms is not so simple.
>>>>>> :/
>>>>>> ill replace the problematic ones by FFMIN/MAX for now so the build
>>>>>> failure on the affected msvc platforms is fixed
>>>>>> tieing a build fix to this complexity would be unwise
>>>>>>> I am definitely interested in getting it to work in order to replace
>>>>>>> FFMAX/FFMIN for floating point in especially libavfilter. This will
>>>>>>> allow better nan signalling at a slight performance cost.
>>>>>> would that performance cost affect all systems or just ones not
>>>>>> having fmin/fmax ?
>>>>>> i think affecting all systems would be bad
>>>>> A correct fmin and fmax will be slower than FFMIN/FFMAX, simply
>>>>> because they do NaN handling. How much slower, I have not tested. Also
>>>>> note that flags may be passed to the compiler to ignore NaN's,
>>>>> something which can possibly be done locally if desired. However, I
>>>>> view FFMAX/FFMIN as the cleaner solution if NaN signalling/propagation
>>>>> is not an issue, so I may not pursue this.
>>>> Common problem with FFMIN/FFMAX (and other macros that evaluates
>>>> arguments more than once):
>>>> FFMAX(a, myfunc(b))
>>>> will call myfunc twice (OK compiler may optimize it and call myfunc once)
>>>> and often people don't care about it.
>>> That goes without saying, but sometimes compiler can't optimize due to
>>> sequence point stuff. This is why the macro should be used cautiously.
>>> However, FFmpeg devs are generally cautious about these things so I no
>>> longer press this that hard. The real technical benefit (if any) is
>>> the different NaN handling as noted above.
>> Here some examples:
>> libavfilter/g729postfilter.c: 544
>>     *voicing = FFMAX(*voicing, long_term_filter(adsp, pitch_delay_int,
>>                                                 residual,
>> residual_filt_buf + 10,
>>                                                 subframe_size));
>> others that call sqrt, strlen, etc (altough possibly compiler can optimize it)
>> commit 94494dab910133106e80ece0f79935d78138e415
>> +        volume = FFABS(av_expr_eval(volume_expr, expr_vars_val, NULL));
>> I posted the patch, and I didn't noticed or warned that it is wrong.
> So on the note of FFABS - I think all floating point usages at least
> have been converted to proper C functions.
> Yes, things like this can be missed, and I personally use the libc
> variants unless there is no alternative.
> However, it was quite some work for me to convince others to use them,
> and I am trying to stay on the sidelines this time by not posting a
> patch for it.
OK, it is just matter of programming style, whatever we choose, has
advantages and deficiency.
The most important thing is that it is work.


More information about the ffmpeg-devel mailing list