On Thu, Oct 29, 2015 at 8:22 AM, Paul B Mahol <one...@gmail.com> wrote: > On 10/29/15, Ganesh Ajjanagadde <gajjanaga...@gmail.com> wrote: >> This is likely more precise and conveys the intent better. >> >> Signed-off-by: Ganesh Ajjanagadde <gajjanaga...@gmail.com> >> --- >> libavfilter/avf_showvolume.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/libavfilter/avf_showvolume.c b/libavfilter/avf_showvolume.c >> index 95b5388..395375a 100644 >> --- a/libavfilter/avf_showvolume.c >> +++ b/libavfilter/avf_showvolume.c >> @@ -197,7 +197,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame >> *insamples) >> max = FFMAX(max, src[i]); >> >> max = av_clipf(max, 0, 1); >> - values[VAR_VOLUME] = 20.0 * log(max) / M_LN10; >> + values[VAR_VOLUME] = 20.0 * log10(max); >> values[VAR_CHANNEL] = c; >> color = av_expr_eval(s->c_expr, values, NULL); >> >> -- >> 2.6.2 > > Have you checked which one is faster? > I really have no opinion on this but gain is neglible.
No, I have not. I suspect, but have not confirmed that log10 is slightly slower: https://stackoverflow.com/questions/10810105/explanation-wanted-log10-faster-than-log-and-log2-but-only-with-o2-and-greater (janneb's comment). Keep in mind their benchmark did not include the cost of a division. I also suspect that this is mostly an artifact of libm, see links: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/ieee754/dbl-64/e_log10.c;hb=HEAD https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/ieee754/dbl-64/e_log2.c;hb=HEAD https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/ieee754/dbl-64/e_log.c;hb=HEAD Basically log10 uses _ieee754_log (essentially log) underneath. No one has taken the trouble of creating a different polynomial, etc for log10. I strongly suspect this is because most clients of libm anyway use log instead of log10, which is arguably rarer. Furthermore, improvements in _ieee754_log are the lowest hanging fruit for them, since due to the above, any improvements there translate into improvements in the other log functions. Lastly, work has been done on optimizing log, and due to the above architecture, log10 inherently relies on it: https://developerblog.redhat.com/2015/01/02/improving-math-performance-in-glibc/ I am pretty sure that if the libm people spent the time to optimize log10 (e.g by creating different polynomial, etc), the gap should narrow. > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
