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 c1f9734f97)
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 73ce8162f3)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 997de2e810)
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 2ea8a48083)
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 0083c16605)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The image decoding code does expect the image to be decoded immedeatly
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from commit d2184bf3b6)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Depending on FPS, the pts_time string often changes length:
... pts_time:36.1 ...
... pts_time:36.1333 ...
etc.
The length changes make the output bounce around horribly, making it
hard to scan down a column farther right than pts_time.
The solution is to set minimum widths for n, pts, pts_time, and pos.
This patch doesn't touch any of the fields in mean / stddev.
The widths aren't intended to be wide enough that they're never
exceeded, but you'll see only an occasional ripple to a new alignment,
rather than bouncing. (Some fields, like pos, increase monotonically,
which is why I left the minimum width for the field be smaller than it
often gets to.)
Signed-off-by: Peter Cordes <peter@cordes.ca>
When precision is fixed and volume is 0, filter_frame does not
perform any operation on the output buffer. This works if the
output buffer has been allocated and zeroed with ff_get_audio_buffer
but not if the input buffer is used as output buffer.
Fix this by not using the input buffer as output buffer if
precision is fixed and volume is 0.
Signed-off-by: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
As far as matrix coefficients are concerned, BT470BG and SMPTE170M
match BT601. This is similar to the check performed in vf_scale.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This makes the sorting of the colors along an axis (r, g or b)
predictible, and thus testable under FATE. The performance is not really
an issue here since the function is called only once at the end and will
need to sort very small number of entries, so an alternative would be to
make the sorting functions (see DECLARE_CMP_FUNC()) fallback on another
axis in case of equality. This approach was actually simpler.
I don't know if there is any advantage in using a multidimensional sort,
but it will affect the final palette one way or another.
* cehoyos/master:
Allow muxing h264 into ts with startcode "001" instead of "0001".
lavfi/fade: Do not overread input buffer.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
