- 14 Jul, 2019 1 commit
-
-
Steve Lhomme authored
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>
-
- 12 Jan, 2019 1 commit
-
-
Michael Niedermayer authored
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/ffmpegSigned-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- 23 Oct, 2018 2 commits
-
-
Josh de Kock authored
-
Devin Heitmueller authored
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.
-
- 09 Oct, 2018 1 commit
-
-
Derek Buitenhuis authored
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>
-
- 17 Aug, 2018 1 commit
-
-
Kieran Kunhya authored
Signed-off-by:
Josh de Kock <joshdk@obe.tv>
-
- 28 Jun, 2018 1 commit
-
-
John Stebbins authored
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>
-
- 12 Apr, 2018 1 commit
-
-
Michael Niedermayer authored
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>
-
- 17 Feb, 2018 1 commit
-
-
Michael Niedermayer authored
Fixes: Integer overflow Fixes: 5746/clusterfuzz-testcase-minimized-6270097623613440 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- 07 Jan, 2018 1 commit
-
-
Michael Niedermayer authored
Fixes: null pointer dereference Fixes: 4698/clusterfuzz-testcase-minimized-5096956322906112 This testcase does not reproduce the issue before 03b82b3a Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- 01 Dec, 2017 2 commits
-
-
James Almer authored
Cosmetic change. Signed-off-by:
James Almer <jamrial@gmail.com>
-
James Almer authored
Cosmetic change. Signed-off-by:
James Almer <jamrial@gmail.com>
-
- 28 Nov, 2017 1 commit
-
-
Vittorio Giovara authored
Implement detection in h264 and hevc and insertion in framepack filter. Signed-off-by:
Vittorio Giovara <vittorio.giovara@gmail.com>
-
- 10 Nov, 2017 1 commit
-
-
Anton Khirnov authored
Some parts of the code are based on a patch by Timo Rothenpieler <timo@rothenpieler.org> Merges Libav commit b9129ec4. 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>
-
- 23 Oct, 2017 1 commit
-
-
Clément Bœsch authored
Deprecated (aka removed) in OSX 10.11, and we have a replacement for it (VideoToolbox).
-
- 12 Sep, 2017 1 commit
-
-
Mark Thompson authored
This avoids confusion with equivalent H.265 SEI values when both are being used at the same time. (cherry picked from commit 6ea220cb)
-
- 10 Aug, 2017 2 commits
-
-
Vittorio Giovara authored
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>
-
Vittorio Giovara authored
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>
-
- 05 Aug, 2017 1 commit
-
-
Michael Niedermayer authored
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/ffmpegSigned-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- 27 Jul, 2017 1 commit
-
-
Wan-Teh Chang authored
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>
-
- 26 Jul, 2017 2 commits
-
-
Anton Khirnov authored
Some parts of the code are based on a patch by Timo Rothenpieler <timo@rothenpieler.org>
-
Anton Khirnov authored
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
-
- 05 Jul, 2017 1 commit
-
-
Michael Niedermayer authored
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/ffmpegSigned-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- 27 Jun, 2017 1 commit
-
-
wm4 authored
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 f9e7a2f9. 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>
-
- 09 Jun, 2017 1 commit
-
-
Michael Niedermayer authored
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/ffmpegSigned-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- 08 Jun, 2017 1 commit
-
-
wm4 authored
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>
-
- 26 May, 2017 2 commits
-
-
James Almer authored
This merges commit c3e84820 from libav, originally written by Anton Khirnov and skipped in fc63d5ce. libavcodec/h264_picture.c | 3 --- libavcodec/h264_ps.c | 9 --------- libavcodec/h264_slice.c | 25 +++++++++++++++++++------ libavcodec/h264dec.c | 13 +------------ libavcodec/h264dec.h | 9 +++++---- 5 files changed, 25 insertions(+), 34 deletions(-)
-
James Almer authored
This merges commit 4fded048 from libav, originally written by Anton Khirnov and skipped in fc63d5ce. libavcodec/h264_slice.c | 20 +++++++++++++------- libavcodec/h264dec.c | 3 +++ libavcodec/h264dec.h | 5 +++++ 3 files changed, 21 insertions(+), 7 deletions(-)
-
- 16 May, 2017 1 commit
-
-
Mark Thompson authored
This avoids confusion with equivalent H.265 SEI values when both are being used at the same time.
-
- 07 Apr, 2017 2 commits
-
-
Ronald S. Bultje authored
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.
-
Michael Niedermayer authored
Fixes: integer overflows Fixes: 911/clusterfuzz-testcase-5415105606975488 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpegReviewed-by:
"Ronald S. Bultje" <rsbultje@gmail.com> Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- 06 Apr, 2017 1 commit
-
-
Ronald S. Bultje authored
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)
-
- 28 Mar, 2017 1 commit
-
-
Ronald S. Bultje authored
The patch introduces race conditions.
-
- 28 Feb, 2017 1 commit
-
-
Michael Niedermayer authored
Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc> Signed-off-by:
Vittorio Giovara <vittorio.giovara@gmail.com>
-
- 14 Feb, 2017 1 commit
-
-
Michael Niedermayer authored
Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- 08 Feb, 2017 1 commit
-
-
Michael Niedermayer authored
Fixes reading freed memory Fixes: 568/clusterfuzz-testcase-6107186067406848 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpegSigned-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- 31 Jan, 2017 1 commit
-
-
Diego Biurrun authored
-
- 19 Jan, 2017 1 commit
-
-
Clément Bœsch authored
-
- 16 Jan, 2017 1 commit
-
-
Clément Bœsch authored
It is done unconditionally in ff_h264_field_end()
-
- 12 Jan, 2017 1 commit
-
-
Anton Khirnov authored
-