This avoids confusion with equivalent H.265 SEI values when both are
being used at the same time.
(cherry picked from commit 6ea220cbeec8863e2006a03b73bed52db2b13ee7)
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>
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 f9e7a2f95a7194a8736cc1416a03a1a0155a3e9f.
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 merges commit 4fded0480f20f4d7ca5e776a85574de34dfead14 from libav,
originally written by Anton Khirnov and skipped in
fc63d5ceb357c4b760cb02772de0b50d0557140f.
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)
* commit '38efff92f1ef81f3de20ff0460ec7b70c253d714':
FATE: add a test for H.264 with two fields per packet
h264: fix decoding multiple fields per packet with slice threads
This merge includes two commits because the FATE test was useful in
order to make proper testing.
The merge gets rid of the now unused:
- SLICE_SINGLETHREAD and SLICE_SKIPED macros
- max_contexts
- "again" label in decode_nal_units()
This commit also includes the fix from d3e4d406b.
Thanks to wm4 and Michael Niedermayer for their testing.
Merged-by: Clément Bœsch <u@pkh.me>
Merged-by: Matthieu Bouron <matthieu.bouron@gmail.com>
* commit 'f450cc7bc595155bacdb9f5d2414a076ccf81b4a':
h264: eliminate decode_postinit()
Also includes fixes from 1f7b4f9abc and e344e65109.
Original patch replace H264Context.next_output_pic (H264Picture *) by
H264Context.output_frame (AVFrame *). This change is discarded as it
is incompatible with the frame reconstruction and motion vectors
display code which needs the extra information from the H264Picture.
Merged-by: Clément Bœsch <u@pkh.me>
Merged-by: Matthieu Bouron <matthieu.bouron@gmail.com>
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>
* commit 'a8cbe5a0ccebf60a8a8b0aba5d5716dd54c1595c':
h264_ps: export actual height in MBs as SPS.mb_height
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
This reverts commit e4af9be0f45c8f2ca148fb971f1e0c6782530e8c and redoes
796027f22154c799e0063e2457b31e0cfd1dddae.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
This reverts commit 796027f22154c799e0063e2457b31e0cfd1dddae, reversing
changes made to bca30ed2b67f095fd31e07319a622ac30ad22978.
Preemptive revert before further testing has been done.
* commit 'b13fc1e344011949929975a3451f78f226aa1de3':
h264: do not pass H264Context to h264_slice_header_parse()
Conflicts:
libavcodec/h264dec.h
Did not merge the h264_slice_header_parse() part. We use a few other
members of H264Context for error checking in that function.
Merged-by: Timothy Gu <timothygu99@gmail.com>
* commit 'bc7f4268514624e1286ea76d27a89a56b4ee18e1':
h264: drop tests whether the codec id is AV_CODEC_ID_H264
Conflicts:
libavcodec/h264dec.c
Merged-by: James Almer <jamrial@gmail.com>
* commit 'f638b67e5790735f34620bf82025c9b9d6fc7216':
h264: move the parameter set definitions to a new header file
Conflicts:
libavcodec/h264_parse.h
libavcodec/h264_ps.c
libavcodec/h264dec.h
Merged-by: James Almer <jamrial@gmail.com>
* commit 'f966498e433fead2f5e6b5b66fad2ac062146d22':
h264: decode the poc values from the slice header into the per-slice context
Merged-by: Clément Bœsch <u@pkh.me>
* commit '54dd9b1cdd9e54f1ee39ae25af0324f8aba2831b':
h264: set mb_aff_frame in frame_start()
h264: move the block starting a new field out of slice_header_parse()
Both commits are merged at the same time in order to prevent a
regression with Ticket #4440 (see 38660128).
Merged-by: Clément Bœsch <u@pkh.me>
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.
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().
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.
* commit '61f168ae348f94f39e7afc6971654455a5de0e4d':
h264: factor out setting the parameter sets for a frame
Michael's changes on top of the merge undo parts of the original diff
that are not factorization:
"The call point is left where it was before. Such a change should be in
a separate commit and has multiple issues, one being null pointer
dereferences the other is that some safety checks would become
conditional.
I tried to split the PPS init between the new and old functions
similarly to the SPS code."
Merged-by: Clément Bœsch <u@pkh.me>
Merged-by: Michael Niedermayer <michael@niedermayer.cc>