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>
