Gain computation for various curves was being done in a needlessly
inaccurate fashion. Of course these are all subjective curves, but when
a curve is advertised to the user, it should be matched as closely as
possible within the limitations of libm. In particular, the constants
kept here were pretty inaccurate for double precision.
Speed improvements are mainly due to the avoidance of pow, the most
notorious of the libm functions in terms of performance. To be fair, it
is the GNU libm that is among the worst, but it is not really GNU libm's fault
since others simply yield a higher error as measured in ULP.
"Magic" constants are also accordingly documented, since they take at
least a minute of thought for a casual reader.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
lrintf is anyway used, suggesting we only care up to floating precision.
Rurthermore, there is a compat hack in avutil/libm for this function,
and it is used in avcodec/aacps_tablegen.h.
This yields a non-negligible speedup. Sample benchmark:
x86-64, Haswell, GNU/Linux:
old (draw_mandelbrot):
274635709 decicycles in draw_mandelbrot, 256 runs, 0 skips
300287046 decicycles in draw_mandelbrot, 512 runs, 0 skips
371819935 decicycles in draw_mandelbrot, 1024 runs, 0 skips
336663765 decicycles in draw_mandelbrot, 2048 runs, 0 skips
581851016 decicycles in draw_mandelbrot, 4096 runs, 0 skips
new (draw_mandelbrot):
269882717 decicycles in draw_mandelbrot, 256 runs, 0 skips
296359285 decicycles in draw_mandelbrot, 512 runs, 0 skips
370076599 decicycles in draw_mandelbrot, 1024 runs, 0 skips
331478354 decicycles in draw_mandelbrot, 2048 runs, 0 skips
571904318 decicycles in draw_mandelbrot, 4096 runs, 0 skips
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
This option can be used to select useful frames from an ffconcat file which is
using inpoints and outpoints but where the source files are not intra frame
only.
Reviewed-by: Stefano Sabatini <stefasab@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
This uses M_SQRT1_2, M_SQRT2 instead of the actual literals. Fixed point
values remain unchanged.
Patch tested with FATE on x86.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
The ad-hoc pi constant has a ludicrous number of digits that offer no
value whatsoever. M_PI is more consistent and readable across the
codebase.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Similar to testsrc, but using drawutils and therefore
supporting a lot of pixel formats instead of just rgb24.
This allows using it as input for other tests without
requiring a format conversion.
It is also slightly faster than testsrc for some reason.
Calculation of x an y based on width and height did not work when
width == 0 or height == 0. "0" substitutes the input width and
height, but did so too late for x, y expression evaluation.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
this makes draw_bar faster
slightly different result with old version
check result (with ~3 minutes audio file):
old:
real 0m49.611s
user 0m49.260s
sys 0m0.073s
new:
real 0m47.606s
user 0m47.378s
sys 0m0.068s
PSNR between old and new:
yuv444p PSNR
y:109.519298 u:107.506485 v:104.746878
average:106.816074 min:99.167305 max:inf
yuv422p PSNR
y:109.519298 u:108.025801 v:104.489734
average:107.279817 min:98.007467 max:inf
yuv420p PSNR
y:109.519298 u:108.363875 v:105.290200
average:108.261511 min:97.461812 max:inf
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
FFDIFFSIGN was created explicitly for this purpose, since the common
return a - b idiom is unsafe regarding overflow on signed integers. It
optimizes to branchless code on common compilers.
FFDIFFSIGN also has the subjective benefit of being easier to read due
to lack of ternary operators.
Tested with FATE.
Things not covered by this are unsigned integers, for which overflows
are well defined, and also places where overflow is clearly impossible,
e.g an instance where the a - b was being done on 24 bit values.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Reviewed-by: Clément Bœsch <u@pkh.me>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
There seems to be some typos in the log messages that are fixed by this.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
This converts the usage of strtod to av_strtod in order to unify and
make number parsing more consistent. This also adds support for SI
postfixes.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Should fix build on x86_32-msvc2012
The alternative of emulating fmin/fmax* turns out to be non trivial
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
