ISO C restricts enumerator values to the range of int. Thus (for instance) 0x80000000
unfortunately does not work, and throws a warning with -Wpedantic on
clang 3.7.
This fixes it by using alternative expressions that result in identical
values but do not have this issue.
Tested with FATE.
Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com> Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
avutil/mathematics: correct documentation for av_gcd
av_gcd is now always defined regardless of input. This documents this
change in the "documented API". Two benefits (closely related):
1. The function is robust, and there is no need to worry about INT64_MIN, etc.
2. Clients of av_gcd, like av_reduce, can now be made fully correct. Currently,
av_reduce can trigger undefined behavior if e.g num is INT64_MIN due to
integer overflow in the FFABS. Furthermore, this undefined behavior is
completely undocumented, and could be a fuzzer's paradise. The FFABS was needed in the past as
av_gcd was undefined for negative inputs. In order to make av_reduce
robust, it is essential to guarantee that av_gcd works for all int64_t.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Steven Robertson [Sun, 11 Oct 2015 01:27:17 +0000 (18:27 -0700)]
vf_lut: Add support for RGB48 and RGBA64.
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 ensures that no undefined behavior is invoked, while retaining
identical return values in all cases and at no loss of performance
(identical asm on clang and gcc).
Essentially, this patch exchanges undefined behavior with implementation
defined behavior, a strict improvement.
Rationale:
1. The ideal solution is to have the return type a uint64_t. This
unfortunately requires an API change.
2. The only pathological behavior happens if both arguments are
INT64_MIN, to the best of my knowledge. In such a case, the
implementation defined behavior is invoked in the sense that UINT64_MAX
is interpreted as INT64_MIN, which any reasonable implementation will
do. In any case, any usage where both arguments are INT64_MIN is a
fuzzer anyway.
3. Alternatives of checking, etc require branching and lose performance
for no concrete gain - no client cares about av_gcd's actual value when
both args are INT64_MIN. Even if it did, on sane platforms (e.g all the
ones FFmpeg cares about), it produces a correct gcd, namely INT64_MIN.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Ronald S. Bultje [Thu, 29 Oct 2015 11:34:37 +0000 (07:34 -0400)]
vp9: update timestamps in ref files using multiple invisible frames.
For the 10-show-existing-frame, the source file indeed has a timestamp
of 3 (or 100/33) for the second visible frame, so the fix appears to
work correctly. For the other, only the timebase is fixed, but again
appears to be correct now.
This one should not trigger any warnings, but will be useful for future
robustness.
Strictly speaking, one could check the size after the call by examining
the structure instead of the return value. Such a use case is highly
unusual, and this commit may be easily reverted if there is a legitimate
need of such use.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
avcodec/motion_est_template: replace qsort with AV_QSORT
This code is in a performance critical section. AV_QSORT is
substantially faster due to the inlining of the comparison callback.
Thus, the increase in performance is worth the increase in binary size.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
avutil/ripemd: make rol macro more robust by adding parentheses
This ensures that the macro remains correct in the sense of allowing
expressions for value and bits, by placing the value and bits expressions within
parentheses.
Reviewed-by: James Almer <jamrial@gmail.com> Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Muhammad Faiz [Sun, 25 Oct 2015 17:18:41 +0000 (00:18 +0700)]
avfilter/avf_showcqt: rewrite showcqt and add features
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>
Hendrik Leppkes [Fri, 23 Oct 2015 11:54:25 +0000 (13:54 +0200)]
avcodec: disallow hwaccel with frame threads
HWAccels with frame threads are fundamentally flawed in avcodecs current
design, and there are several known problems ranging from image corruption
to driver crashes.
These problems come down to two design problems in the interaction of
threads and HWAccel decoding:
(1)
While avcodec prevents parallel decoding and as such simultaneous access
to the hardware accelerator from the decoding threads, it cannot account
for the user code and its access to the hardware surfaces and the hardware
itself.
This can result in image corruption or even driver crashes if the
user code locks image surfaces while they are being used by the decoder
threads as reference frames.
The current HWAccel API does not offer any way to ensure exclusive access
to the hardware or the surfaces if frame threading is used.
(2)
Initialization of the HWAccel with frame threads is non-trivial, and many
decoders had and still have issues that cause excess calls to the
get_format callback.
This will potentially cause duplicate HWAccel initialization, which in
extreme cases can even lead to driver crashes if the HWAccel is
re-initialized while the user code is actively accessing the hardware
surfaces associated with it, or lead to image corruption due to lost
reference frames.
While both of these issues are solvable, fixing (1) would at least require
a huge API redesign which would move a lot of complexity into the user
code.
The only reason the combination of frame threads and HWAccel was
considered useful is to allow a seamless fallback to multi-threaded
software decoding if the HWAccel is not available, however the issues
outlined above far outweigh this.
The proper solution for a fallback is to re-open the AVCodecContext with
threading enabled if the HWAccel failed, which is a practice commonly used
by various user applications using avcodec today already.
projects / ffmpeg / log