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>
This documents the additional constness, and provides a useful libc
reference for the API specification of the comparator.
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>
This fixes extra semicolons that clang 3.7 on GNU/Linux warns about.
These were trigggered when built under -Wpedantic, which essentially
checks for strict ISO compliance in numerous ways.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
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>
Current code segfaults since the deprecation of AVSubtitleRect.pict because it
freed/realloced AVSubtitleRect.pict.data by itself.
The new code stores the generated YUVA AVSubtitle rectangles in their own
struct and keeps the original AVSubtitle structure untouched, because
overwriting it is considered invalid API usage.
Signed-off-by: Marton Balint <cus@passwd.hu>
GCC (and Clang) have this useful warning that is not enabled by -Wall or
-Wextra. This will ensure that issues like those fixed in
4da52e3630
will trigger warnings.
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Some server in the wild do not put the boundary at a newline
as rfc1347 7.2.1 states.
Cope with that by reading a line and if it is not empty reading
a second one.
Reported-By: bitingsock
mp3 packets all have the same duration and number of samples
if their duration indicated in the container varies then thats an
indication that they are not 1 mp3 packet each.
If this autodetection fails for some case then please contact us
and provide a testcase.
Fixes Ticket4938
This also makes sure that a fragmented file without the empty_moov
flag (i.e. with a non-empty initial moov fragment) actually gets
written, if some of the tracks turn out to not have any samples.
Signed-off-by: Martin Storsjö <martin@martin.st>
Some RTSP servers ("HiIpcam/V100R003 VodServer/1.0.0") respond to
our keepalive GET_PARAMETER request by a truncated RTSP header
(lacking the final empty line to indicate a complete response
header). Prior to 764ec70149, this worked just fine since we
reacted to the $ as interleaved packet indicator anywhere.
Since $ is a valid character within the response header lines,
764ec70149 changed it to be ignored there. But to keep
compatibility with such broken servers, we need to at least
allow reacting to it at the start of lines.
Signed-off-by: Martin Storsjö <martin@martin.st>
This does not trigger any warnings, but adds robustness.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
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>
* commit '3ee2c60cc296eee3f63d7b5fee9b4332eeeac9fa':
utils: Use data buffers directly instead of an AVPicture
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'ff7956fcbf8e59b21654b95038de3ed88a850a9e':
avplay: Replace avpicture functions with imgutils
avplay and ffplay have diverged quite a bit, and ffplay should be updated
independently.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
* commit 'f890677d05bc4e8b494a73373ab4cc19791bf884':
Replace any remaining avpicture function with imgutils
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
