Currently, if the movie source filter is used and a seek_point is
specified on a file that has a negative start time, ffmpeg will fail.
An easy way to reproduce this is as follows:
$ ffmpeg -vsync passthrough -filter_complex 'color=d=10,setpts=PTS-1/TB' test.mp4
$ ffmpeg -filter_complex 'movie=filename=test.mp4:seek_point=2' -f null -
The problem is caused by checking for int64_t overflow the wrong way.
In general, to check whether a + b overflows, it is not enough to do:
a > INT64_MAX - b
because b might be negative; the correct way is:
b > 0 && > a > INT64_MAX - b
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit c1f9734f977f59bc0034096afbe8e43e40d93a5d)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Prevents that following scalers in the filter chain will do unintentional color range conversions.
Fixes Ticket #5096
Signed-off-by: Thomas Mundt <loudmax@yahoo.de>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 73ce8162f3499cf0e86d1d80dea53324bd62bcb3)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 997de2e8107cc4256e50611463d609b18fe9619f)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
long may not be 64 bit on all platforms; so labs on int64_t is unsafe.
This fixes a warning reported in:
http://fate.ffmpeg.org/log.cgi?time=20150905071512&log=compile&slot=i386-darwin-clang-polly-3.7
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit d74123d03eb1047b844bc39fbde26f199c72cbcb)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signal_sigabrt_7ffff70eccc9_498_divx502.avi with memlimit 1572864
Found-by: Samuel Groß, Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 2ea8a480832acad3095783bcb11d5f290bec56cf)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes out of array access
Fixes: asan_heap-oob_7f875d_3482_cov_1818465256_ssudec.mov
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit 0083c16605aa5997534e87e68f97ef85a8c3b7b8)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
calc_coefficients is no longer being called every frame
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
It's often really helpful to know why a frame wasn't decimated (lo or
hi), and how much you exceeded the threshold by, if you're trying to
tweak the thresholds to get what you want.
mpdecimate already prints a line per input frame with -v debug, this
just makes it longer.
Signed-off-by: Peter Cordes <peter@cordes.ca>
With bps > 8 more than 255..255 are used
The initialized table content is left unchanged,
But it could also be adjusted for the slight difference of
the maximum
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '7046bd9bc9ce04521edf453c9b603d84d69c7512':
lavfi: Move avcodec header to the only filter needing it
Conflicts:
libavfilter/avfilter.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
benchmark (on intel core2 duo, gcc 4.9.1)
input samples duration 00:03:39.59
command: time -p ffmpeg -f f32le -ac 2 -ar 44100 -i input.pcm \
-filter_complex showcqt=fullhd=0:gamma=$gamma \
-f rawvideo -y /dev/null
gamma previous modified
1 48.49 s 45.38 s
2 49.33 s 48.11 s
3 80.86 s 59.80 s
4 80.84 s 51.25 s
5 80.75 s 61.06 s
6 80.93 s 61.80 s
7 80.03 s 61.56 s
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
