as well as includes of libavutil/timer.h.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It's better to do it before the buffers are actually created. At least in VLC
we currently don't support changing some parameters dynamically easily so we
don't use the information if it comes after the buffer are created.
Co-authored-by: James Almer <jamrial@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: signed integer overflow: 2 * 2132811760 cannot be represented in type 'int'
Fixes: 11156/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-6237685933408256
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Create SMPTE ST 12-1 timecodes based on H.264 SEI picture timing
info.
For framerates > 30 FPS, the field flag is used in conjunction with
pairs of frames which contain the same frame timestamp in S12M.
Ensure the field is properly set per the spec.
If we don't copy this value first, it is seen as 0 by h264_slice_header_init,
due to zero-allocation of the new context, triggering an old hack that
multiplied the denominator by 2 for files produced by old x264 versions, but
only if more than one thread was used.
Fixes#7475 and #7083.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
When not using libavformat for demuxing, AVCodecContext.has_b_frames
gets set too late causing the recovery frame heuristic in h264_refs to
incorrectly flag an early frame as recovered.
This patch sets has_b_frames earlier to prevent improperly flagging the
frame as recovered.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 2147483646 - -2816 cannot be represented in type 'int'
Fixes: crbug 823145
Reported-by: Matt Wolenetz <wolenetz@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: null pointer dereference
Fixes: 4698/clusterfuzz-testcase-minimized-5096956322906112
This testcase does not reproduce the issue before 03b82b3ab9
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Some parts of the code are based on a patch by
Timo Rothenpieler <timo@rothenpieler.org>
Merges Libav commit b9129ec466.
Due to the name clash with our cuvid decoder, rename it to nvdec.
This commit also changes the Libav code to dynamic loading of the
cuda/cuvid libraries.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
The use of this SEI is for backward compatibility in HLG HDR systems:
older devices that cannot interpret the "arib-std-b67" transfer will
get the compatible transfer (usually bt709 or bt2020) from the VUI,
while newer devices that can interpret HDR will read the SEI and use
its value instead.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
The use of this SEI is for backward compatibility in HLG HDR systems:
older devices that cannot interpret the "arib-std-b67" transfer will
get the compatible transfer (usually bt709 or bt2020) from the VUI,
while newer devices that can interpret HDR will read the SEI and use
its value instead.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Fixes: runtime error: signed integer overflow: 1610612736 * 2 cannot be represented in type 'int'
Fixes: 2817/clusterfuzz-testcase-minimized-5289691240726528
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
default_ref[] is unconditionally initialized in h264_initialise_ref_list()
(called from ff_h264_build_ref_list(), called from h264_slice_init()).
This fixes the following tsan warning when running fate-h264:
WARNING: ThreadSanitizer: data race (pid=31070)
Write of size 8 at 0x7bbc000082a8 by thread T1 (mutexes: write M1628):
#0 memcpy /work/release-test/final/llvm.src/projects/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_common_interceptors.inc:655:5
(ffmpeg+0x10de9d)
#1 h264_initialise_ref_list ffmpeg/libavcodec/h264_refs.c:214:29 (ffmpeg+0x1186b3f)
#2 ff_h264_build_ref_list ffmpeg/libavcodec/h264_refs.c:306 (ffmpeg+0x1186b3f)
#3 h264_slice_init ffmpeg/libavcodec/h264_slice.c:1900:11 (ffmpeg+0x1191149)
[..]
Previous read of size 8 at 0x7bbc000082a8 by main thread (mutexes:
write M1630):
#0 memcpy /work/release-test/final/llvm.src/projects/compiler-rt/lib/tsan/../sanitizer_common/sanitizer_common_interceptors.inc:655:5
(ffmpeg+0x10de9d)
#1 ff_h264_update_thread_context ffmpeg/libavcodec/h264_slice.c:411:5 (ffmpeg+0x118b7dc)
Signed-off-by: Wan-Teh Chang <wtc@google.com>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Do not use the one in the SEI directly as that is reset at certain
points.
Inspired by patches from Michael Niedermayer <michaelni@gmx.at> and
Anton Mitrofanov <BugMaster@narod.ru>.
CC: libav-stable@libav.org
Fixes: runtime error: signed integer overflow: 26 + 2147483644 cannot be represented in type 'int'
Fixes: 2456/clusterfuzz-testcase-minimized-4822695051001856
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This also adds support to avconv (which is trivial due to the new
hwaccel API being generic enough).
The new decoder setup code in dxva2.c is significantly based on work by
Steve Lhomme <robux4@gmail.com>, but with heavy changes/rewrites.
Merges Libav commit f9e7a2f95a.
Also adds untested VP9 support.
The check for DXVA2 COBJs is removed. Just update your MinGW to
something newer than a 5 year old release.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Fixes: runtime error: index 49 out of bounds for type 'int [48][2][2]'
Fixes: 2159/clusterfuzz-testcase-minimized-5267945972301824
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This also adds support to avconv (which is trivial due to the new
hwaccel API being generic enough).
The new decoder setup code in dxva2.c is significantly based on work by
Steve Lhomme <robux4@gmail.com>, but with heavy changes/rewrites.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
This merges commit 4fded0480f from libav,
originally written by Anton Khirnov and skipped in
fc63d5ceb3.
libavcodec/h264_slice.c | 20 +++++++++++++-------
libavcodec/h264dec.c | 3 +++
libavcodec/h264dec.h | 5 +++++
3 files changed, 21 insertions(+), 7 deletions(-)
I'm hoping that this will address the remaining tsan fate-h264 issues:
WARNING: ThreadSanitizer: data race (pid=24478)
Read of size 8 at 0x7dbc0001c828 by main thread (mutexes: write M3243):
#0 ff_h264_ref_picture src/libavcodec/h264_picture.c:107 (ffmpeg+0x0000013b78d8)
[..]
Previous write of size 1 at 0x7dbc0001c82e by thread T2 (mutexes: write M3245):
#0 ff_h264_direct_ref_list_init src/libavcodec/h264_direct.c:137 (ffmpeg+0x000001382c93)
But I'm not sure because I haven't been able to reproduce locally.
This tries to handle cases where separate invocations of decode_frame()
(each running in separate threads) write to respective fields in the
same AVFrame->data[]. Having per-field owners makes interaction between
readers (the referencing thread) and writers (the decoding thread)
slightly more optimal if both accesses are field-based, since they will
use the respective producer's thread objects (mutex/cond) instead of
sharing the thread objects of the first field's producer.
In practice, this fixes the following tsan-warning in fate-h264:
WARNING: ThreadSanitizer: data race (pid=21615)
Read of size 4 at 0x7d640000d9fc by thread T2 (mutexes: write M1006):
#0 ff_thread_report_progress pthread_frame.c:569 (ffmpeg:x86_64+0x100f7cf54)
[..]
Previous write of size 4 at 0x7d640000d9fc by main thread (mutexes: write M1004):
#0 update_context_from_user pthread_frame.c:335 (ffmpeg:x86_64+0x100f81abb)
The current condition can trigger in cases where it shouldn't, with
unexpected results.
Make sure that:
- container cropping is really based on the original dimensions from the
caller
- those dimenions are discarded on size change
The code is still quite hacky and eventually should be deprecated and
removed, with the decision about which cropping is used delegated to the
caller.
Calling ff_h264_field_end() when the per-field state is not properly
initialized leads to all kinds of undefined behaviour.
CC: libav-stable@libav.org
Bug-Id: 977 978 992
This could happen when there was a frame number gap and frame threading was used.
Debugging-by: Ronald S. Bultje <rsbultje@gmail.com>
Debugging-by: Justin Ruggles <justin.ruggles@gmail.com>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
CC:libav-stable@libav.org
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This could happen when there was a frame number gap and frame threading was used.
This fixes#5458.
Debugging-by: Ronald S. Bultje <rsbultje@gmail.com>
Debugging-by: Justin Ruggles <justin.ruggles@gmail.com>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This reverts commit 796027f22154c799e0063e2457b31e0cfd1dddae, reversing
changes made to bca30ed2b6.
Preemptive revert before further testing has been done.
Anton Khirnov
Andreas Rheinhardt
Michael Niedermayer
Steve Lhomme
Josh de Kock
Devin Heitmueller
Derek Buitenhuis
Kieran Kunhya
John Stebbins
James Almer
Vittorio Giovara
Clément Bœsch
Mark Thompson
Wan-Teh Chang
wm4
Ronald S. Bultje
Diego Biurrun
Clément Bœsch
Timothy Gu