lrint is faster, and is more consistent across the codebase.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Do not clip output samples, so that clipping can be handled by other filters.
Alow setting curve points above 0dB. This is useful when operating with floats.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
This is likely more precise and conveys the intent better.
Reviewed-by: Mark Harris <mark.hsj@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Remove all modes except levels mode.
Users should already switch to other filters with
extended funcionality: vectorscope and waveform.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
Fix color fading: previously color could fade to red when
volume level for red color was actually never reached.
Display volume value on right side.
Use red color only if clipping is needed.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
This removes wasteful pow(x, 2.0) that although not terribly important
for speed, is still useless.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
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>
Paul B Mahol
Clément Bœsch
Clément Bœsch
Ganesh Ajjanagadde
Michael Niedermayer
Timothy Gu
Marton Balint
John Stebbins
Michael Niedermayer