- 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 2 commits
-
-
Anton Khirnov authored
-
Anton Khirnov authored
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.
-
- 09 Jan, 2017 1 commit
-
-
Anton Khirnov authored
Cropping parameters are already checked for validity during SPS parsing, no need to check them again.
-
- 19 Dec, 2016 1 commit
-
-
Anton Khirnov authored
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
-
- 14 Dec, 2016 1 commit
-
-
Derek Buitenhuis authored
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>
-
- 09 Dec, 2016 1 commit
-
-
Derek Buitenhuis authored
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>
-
- 04 Aug, 2016 2 commits
-
-
Timothy Gu authored
This reverts commit e4af9be0 and redoes 796027f2. Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
-
Timothy Gu authored
This reverts commit 796027f2, reversing changes made to bca30ed2. Preemptive revert before further testing has been done.
-
- 27 Jul, 2016 2 commits
-
-
Michael Niedermayer authored
-
Clément Bœsch authored
-
- 19 Jul, 2016 1 commit
-
-
Michael Niedermayer authored
This was missing from f512e4a3Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
-
- 15 Jul, 2016 2 commits
-
-
Anton Khirnov authored
Since we only know whether a NAL unit corresponds to a new field after parsing the slice header, this requires reorganizing the calls to slice parsing, per-slice/field/frame init and actual decoding. In the previous code, the function for slice header decoding also immediately started a new field/frame as necessary, so any slices already queued for decoding would no longer be decodable. After this patch, we first parse the slice header, and if we determine that a new field needs to be started we decode all the queued slices.
-
Anton Khirnov authored
This function's purpose is not very well defined. Currently it does two (only marginally related) things: selecting the next output frame and calling ff_thread_finish_setup() for frame threading. The first of those more properly belongs under field_start(), while the second can be called directly from decode_nal_units().
-
- 11 Jul, 2016 1 commit
-
-
Anton Khirnov authored
Currently, SPS.mb_height is actually what the spec calls PicHeightInMapUnits, which is half the frame height when interlacing is allowed. Calling this 'mb_height' is quite confusing, and there are at least two associated bugs where this field is treated as the actual frame height - in the h264 parser and in the code computing maximum reordering buffer size for a given level. Fix those issues (and avoid possible future ones) by exporting the real frame height in this field.
-