[FFmpeg-devel] [PATCH 2/3] lavu/internal: add avpriv_exp10

Ganesh Ajjanagadde gajjanag at mit.edu
Fri Dec 25 20:01:05 CET 2015


On Fri, Dec 25, 2015 at 9:55 AM, Ganesh Ajjanagadde <gajjanag at mit.edu> wrote:
> On Fri, Dec 25, 2015 at 9:47 AM, Hendrik Leppkes <h.leppkes at gmail.com> wrote:
>> On Fri, Dec 25, 2015 at 6:27 PM, Ganesh Ajjanagadde <gajjanag at mit.edu> wrote:
>>> On Fri, Dec 25, 2015 at 9:26 AM, James Almer <jamrial at gmail.com> wrote:
>>>> On 12/25/2015 2:11 PM, Ganesh Ajjanagadde wrote:
>>>>> Fast, reasonably accurate 10^x. Alternative of detection of libm exp10 at configure
>>>>> time is not worth the trouble, since it is anyway not POSIX or ISO C,
>>>>> and currently only the GNU libm has it. Furthermore, GNU libm's variant
>>>>> is ~ 2x slower, and is ironically not correctly rounded (2 ulp off) to justify all
>>>>> that slowdown.
>>>>>
>>>>> Reviewed-by: Michael Niedermayer <michael at niedermayer.cc>
>>>>> Signed-off-by: Ganesh Ajjanagadde <gajjanagadde at gmail.com>
>>>>> ---
>>>>>  libavutil/internal.h | 19 +++++++++++++++++++
>>>>>  1 file changed, 19 insertions(+)
>>>>>
>>>>> diff --git a/libavutil/internal.h b/libavutil/internal.h
>>>>> index f86b7fb..ae11601 100644
>>>>> --- a/libavutil/internal.h
>>>>> +++ b/libavutil/internal.h
>>>>> @@ -292,6 +292,25 @@ static av_always_inline av_const int64_t ff_rint64_clip(double a, int64_t amin,
>>>>>      return res;
>>>>>  }
>>>>>
>>>>> +/**
>>>>> + * Compute 10^x for floating point values. Note: this function is by no means
>>>>> + * "correctly rounded", and is meant as a fast, reasonably accurate approximation.
>>>>> + * For instance, maximum relative error for the double precision variant is
>>>>> + * ~ 1e-13 for very small and very large values.
>>>>> + * This is ~2x faster than GNU libm's approach, which is still off by 2ulp on
>>>>> + * some inputs.
>>>>> + * @param x exponent
>>>>> + * @return 10^x
>>>>> + */
>>>>> +static av_always_inline double avpriv_exp10(double x)
>>>>
>>>> It's an inline function in a header, and internal at that. Just call it ff_exp10.
>>>
>>> It is used in avcodec and avfilter. I thought this meant that it
>>> should be avpriv?
>>> Personally, I like ff_exp10 as it is shorter.
>>>
>>
>> avpriv is a hack for private functions that need to be exported in
>> shared libraries, since we have a rule to only export av* functions.
>
> Makes sense now.
>
>> inline functions in headers don't need to be exported in a library, so
>> no need for avpriv. ff* is fine there, and used for other similar
>> situations.
>
> Guess the patch is ok (once this is changed), and likewise the
> configure one. Both of these going in soon. Thanks.

pushed

>
>>
>> - Hendrik
>> _______________________________________________
>> ffmpeg-devel mailing list
>> ffmpeg-devel at ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


More information about the ffmpeg-devel mailing list