complex is not available on all platforms. Furthermore, it is trivial to
rewrite complex number expressions to real arithmetic, and in fact
sometimes advantageous for performance reasons: by wrapping as a complex,
one forces a particular Cartesian representation that is not necessarily optimal for the purpose.
Configure dependencies also removed, and aemphasis is now available across
all platforms.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Instead of calling the input filter request_frame() method,
ff_request_frame() now marks the link and returns immediately.
buffersink is changed to activate the marked filters until
a frame is obtained.
The status field can carry any error code instead of just EOF.
Also only update it through a wrapper function and provide a timestamp.
Update the few filters that used it directly.
Applications are not supposed to mess with links,
they should close the sinks.
Furthermore, this function does not distinguish what end
of the link caused the close and does not have a timestamp.
This field is used for fast comparison between link ages,
it is in AV_TIME_BASE units, in other words microseconds,
µs =~ us.
Renaming it allows a second field in link time base units.
lrint avoids an implicit cast, and is not slower on non-broken libm's. Thus this
represents a Pareto improvement.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
lrint is faster here on -ftree-vectorize with GCC. This is likely simply
an artifact of GCC's rather terrible auto-vectorizer, since as per the
instruction set manuals cvtsd2si and cvttsd2si (or their vector equivalents)
have identical cycle timings.
Anyway, regardless of above, lrint is superior to round accuracy wise.
Safety guaranteed as long int has at least 32 bits.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
lrint is at least as fast, and is more accurate.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
lrint is at least as fast, and more accurate.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
lrint is faster and conveys the intent better here. It is safe as long int has
at least 32 bits.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
In the code we keep using logo_x2-1 and logo_y2-1 rather than logo_x2
and logo_y2 themselves. Define them to be what we need instead, to avoid
the repeated subtractions.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The show option did not take clipping into account, so the borders on
the clipped side wouldn't show up. Fix it.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Relying on AVPixFmtDescriptor.nb_components is cleaner and faster than
checking data and linesize for every possible plane.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is a somewhat subtle failure that can occur when the realloc_array
fails in FORMATS_REF.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
pow is a ridiculous function for computing a simple Gaussian.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Recent commits 6aaac24d72 and
3835554bf8 made progress towards cleaning
up usage of the formats API, and in particular fixed possible NULL pointer
dereferences.
This commit addresses the issue of possible resource leaks when some intermediate
call fails.
Tested with valgrind --leak-check=full --show-leak-kinds=all, and manual simulation
of malloc/realloc failures.
Fixes: CID 1250334.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Recent commits 6aaac24d72 and
3835554bf8 made progress towards cleaning
up usage of the formats API, and in particular fixed possible NULL pointer
dereferences.
This commit addresses the issue of possible resource leaks when some intermediate
call fails.
Tested with valgrind --leak-check=full --show-leak-kinds=all, and manual simulation
of malloc/realloc failures.
Fixes: CID 1338330.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Recent commits 6aaac24d72 and
3835554bf8 made progress towards cleaning
up usage of the formats API, and in particular fixed possible NULL pointer
dereferences.
This commit addresses the issue of possible resource leaks when some intermediate
call fails.
Tested with valgrind --leak-check=full --show-leak-kinds=all, and manual simulation
of malloc/realloc failures.
Fixes: CID 1338326, 1338329.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Recent commits 6aaac24d72 and
3835554bf8 made progress towards cleaning
up usage of the formats API, and in particular fixed possible NULL pointer
dereferences.
This commit addresses the issue of possible resource leaks when some intermediate
call fails.
Tested with valgrind --leak-check=full --show-leak-kinds=all, and manual simulation
of malloc/realloc failures.
Fixes: CID 1338327.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Recent commits 6aaac24d72 and
3835554bf8 made progress towards cleaning
up usage of the formats API, and in particular fixed possible NULL pointer
dereferences.
This commit addresses the issue of possible resource leaks when some intermediate
call fails. Unfortunately, even leaving aside this subtle intermediate
failure aspect, commit 8087632027 was only
partially successful in addressing memleaks. Hopefully, this commit
fixes the issue completely.
Tested with valgrind --leak-check=full --show-leak-kinds=all, and manual simulation
of malloc/realloc failures.
Fixes: CID 1270818.
Reviewed-by: Clément Bœsch <u@pkh.me>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
When the interpolated value is divided by the sum of weights, no
rounding is done, which means the value is truncated. This results in
a slight bias towards dark green in the interpolated area. Rounding
properly removes the bias.
I measured this change to reduce the interpolation error by 1 to 2 %
on average on a number of sample input and logo area combinations.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
fix default basefreq/endfreq comparison
on platform that does not do comparison
in double type
found on zeranoe 32-bit build, where
default freq range is detected as non-default
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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>
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>
Signed-off-by: Steven Robertson <steven@strobe.cc>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is likely more precise and conveys the intent better.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
This is likely more precise and conveys the intent better.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
This is likely more precise and conveys the intent better.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
This is likely more precise and conveys the intent better.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
This is likely more precise and conveys the intent better.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
add yuv444p, yuv422p, and yuv420p output format (lower cpu usage
on ffplay playback because it does not do format conversion)
custom size with size/s option (fullhd option is deprecated)
custom layout with bar_h, axis_h, and sono_h option
support rational frame rate (within fps/r/rate option)
relaxed frame rate restriction (support fractional sample step)
support all input sample rates
separate sonogram and bargraph volume (with volume/sono_v and
volume2/bar_v)
timeclamp option alias (timeclamp/tc)
fcount option
gamma option alias (gamma/sono_g and gamma2/bar_g)
support custom frequency range (basefreq and endfreq)
support drawing axis using external image file (axisfile option)
alias for disabling drawing to axis (text/axis)
possibility to optimize it using arch specific asm code
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
libc's qsort comparator has a const qualifier on both arguments. This
adds a missing const qualifier to exactly match the comparator API.
Existing usages of av_tree_find, av_tree_insert are appropriately
modified: type signature changes of the comparators, and removal of
unnecessary void * casts of function pointers.
Reviewed-by: Henrik Gramner <henrik@gramner.com>
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
For generality, qsort uses a comparator whose elements are void *. This
makes the comparator have such a form, and thus makes the void * cast of
the comparator pointer useless. Furthermore, this makes the code more
consistent with other usages of qsort across the codebase.
Reviewed-by: Henrik Gramner <henrik@gramner.com>
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
These casts are unnecessary, and may safely be removed.
Found by enabling -Wpedantic on clang 3.7.
Tested with FATE.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
ISO C requires at least one argument in the place of the ellipsis in a
variadic macro. In particular, under -pedantic, this triggers the
warning -Wgnu-zero-variadic-macro-arguments on clang 3.7.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
It is well known that fabs and fabsf are at least as fast and sometimes
faster than the FFABS macro, at least on the gcc+glibc combination.
For instance, see the reference:
http://patchwork.sourceware.org/patch/6735/.
This was a patch to glibc in order to remove their usages of a macro.
The reason essentially boils down to fabs using the __builtin_fabs of
the compiler, while FFABS needs to infer to not use a branch and to
simply change the sign bit. Usually the inference works, but sometimes
it does not. This may be easily checked by looking at the asm.
This also has the added benefit of reducing macro usage, which has
problems with side-effects.
Note that avcodec is not handled here, as it is huge and
most things there are integer arithmetic anyway.
Tested with FATE.
Reviewed-by: Clément Bœsch <u@pkh.me>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
This clarifies and adds Doxygen for ff_fmt_is_in.
Reviewed-by: Timothy Gu <timothygu99@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
av_warn_unused_result is added to functions whose return status should
be checked. Currently does not trigger any warnings, but should be
useful for future robustness.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Commit bf0d2d6030 introduced
av_warn_unused_result to avfilter/formats, whose associated warnings
were mostly fixed in 6aaac24d72. This
fixes the issues in avfilter/avfiltergraph.
Tested with FATE.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Filters which support such changes should be excluded from these checks
Fixes Ticket4884
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This uses the av_warn_unused_result attribute liberally to catch some forms of improper
usage of functions defined in avfilter/formats.h.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Many of the functions from avfilter/formats can return errors, usually AVERROR(ENOMEM).
This propagates the return values.
All of these were found by using av_warn_unused_result, demonstrating its utility.
Tested with FATE. I am least sure of the changes to avfilter/filtergraph,
since I don't know what/how reduce_format is intended to behave and how it should
react to errors.
Fixes: CID 1325680, 1325679, 1325678.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Previous version Reviewed-by: Nicolas George <george@nsup.org>
Previous version Reviewed-by: Clément Bœsch <u@pkh.me>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
This adds av_warn_unused_result whenever it is relevant.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
The original interpolation algorithm behaved poorly on the borders and
did not even guarantee continuity at the borders. For this reason, a
second interpolation/blending pass was required on the borders to make
them seamless.
However, since the interpolation algorithm was improved in June 2013,
the border issues no longer exist. The new algorithm does guarantee
continuity at the borders, making the second pass useless. A larger
band always increases the cumulated interpolation error. In most cases
it also increases the average interpolation error, even though the
samples in the band are only partially interpolated.
For this reason I would like to get rid of the "band" parameter. As a
first step, let's change its default value from 4 to 1 and document it
as deprecated.
I have benchmarked this change on a combination of input sources and
realistic logo areas. Lowering the band value from 4 to 1 resulted in
8 to 39 % less interpolation error per frame (or 1 to 34 % less
interpolation error per luma sample.)
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Stefano Sabatini <stefasab@gmail.com>
* commit 'c9943f00cfa2471d1b8a3a9ddc7a21049a71090e':
vf_framepack: Use av_image_copy() where appropriate
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
This correctly adjust chroma subsampling for column interleaved mode,
and allows future high bitdepth support.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
* commit 'ae25413daf42a06f078ed81bb545ec23a8e0b482':
lavfi: do not exclude hwaccel formats from ff_all_formats()
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
The code assumed that the outermost interpolated pixels were always in
the fuzzy area defined by the band option. However if the band value
is small, there may be no fuzzy area on a given plane. In that case,
option show did not work, no rectangle was drawn (or only on the luma
plane, depending on the band value and chroma plane subsampling
factors.)
Fix the problem by not making any assumption on where the outermost
interpolated pixels will be.
The new code was verified to produce the same result as the original
code when the band value is not small.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
For yuv420p, the chroma position is unilaterally overriden, even
if ffmpeg's command-line explicitly set it. To fix this, override
only if the value is the default one.
Regression since 1515bfb3.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It requires a loop in filters or the framework,
that makes the scheduling less efficient and more complex.
This is purely an internal change since the loop is now
present in buffersink.
Note that no filter except buffersink did rely on the requirement.
Do not assume that ff_request_frame() returning success
implies a frame has arrived in the FIFO.
Instead, just loop until a frame is in the FIFO.
It does not change anything since the same loop is present
in ff_request_frame(), confirmed by an assertion.
This resolves implementation defined behavior, and also silences -Wabsolute-value in clang 3.5+.
Moreover, the generated asm is identical to before modulo nop padding.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
faster initialization and less code
slightly different result computationally from previous
coeffclamp option is ignored
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
