The code uses int, unsigned int and uint16_t to store num_entry_point_offsets
This limits it to the smallest of the 3.
Alternatively uint16_t can be changed and then a larger limit used.
A Check will still be needed.
Fixes: 391974932/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5966648879677440
Fixes: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: shift exponent 49 is too large for 32-bit type 'int'
Fixes: 398060145/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5023082406543360
Reviewed-by: James Almer <jamrial@gmail.com>
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Abort as soon as we're done reading the slice header instead of running extra checks
that assume slice data may follow.
Signed-off-by: James Almer <jamrial@gmail.com>
Prevents printing bogus errors about the value being 0, when in fact we
overread the available slice buffer.
Signed-off-by: James Almer <jamrial@gmail.com>
All users (namely HEVC) that use ff_progress_frame_alloc()
should just use ff_thread_get_buffer(). Using
ff_progress_frame_get_buffer() is not a must; it is merely
a convenience wrapper.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is simpler, avoids several loops and also makes GCC no longer
emit bogus -Wstringop-overflow= warnings.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This commit adds a reference to the buffer as an argument to
start_frame, and adapts all existing code.
This allows for asynchronous hardware accelerators to skip
copying packet data by referencing it.
The ///< or /**< form of doxygen comments are only to be used
when the documentation follows the member and the comment
block starts on the same line as the member. This commit
fixes wrong uses of them; in particular, this fixes the comment
for mb_height in H.264 SPS's structure which was wrongly added
to mb_width.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Remove a for loop and make it easy to extend to support other types
of scalability. Move ScalabilityMask to hevc header file so it can
be used in hevc decoder.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
This commit adds support for 4:2:2 decoding for HEVC and H.264 on
NVIDIA Blackwell GPUs. Additionally, it supports 10-bit decoding
for H.264 on Blackwell GPUs.
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
`POS(1,` and `POS(2,` may trigger UBSAN report:
"runtime error: applying non-zero offset 304 to null pointer"
Looks like values are not used without `chroma_format_idc`,
so maybe there is no other issues than the UB.
Can't reproduce with "fate".
Signed-off-by: Vitaly Buka <vitalybuka@google.com>
Signed-off-by: James Almer <jamrial@gmail.com>
These properties are unreliable because they depend on the frames decoded so
far, users should check directly the presence of the decoded AVFrame side data
or AVFrame flags.
Signed-off-by: Marton Balint <cus@passwd.hu>
This can be useful in other places, e.g. it can replace objpool in
fftools.
The API is modified in the following nontrivial ways:
* opaque pointers can be passed through to all user callbacks
* read and write were previously separate callbacks in order to
accomodate the caller wishing to write a new reference to the FIFO and
keep the original one; the two callbacks are now merged into one, and
a flags argument is added that allows to request such behaviour on a
per-call basis
* new peek and drain functions
This does not replicate on my setup, thus this is a blind fix based on ossfuzz trace
Fixes: use of uninitialized value
Fixes: 71747/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5427736120721408
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
And ensure the buffer is synced between threads.
Based on a patch by Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: James Almer <jamrial@gmail.com>
This removes the ABI breaking use of sizeof(AVFilmGrainParams), and achieves the
same size reduction to decoder structs as 08b1bffa49.
Signed-off-by: James Almer <jamrial@gmail.com>
AVFilmGrainAFGS1Params, the offending struct, is using sizeof(AVFilmGrainParams)
when it should not. This change also forgot to make the necessary changes to the
frame threading sync code.
Both of these will be fixed by the following commit.
H274FilmGrainDatabase will be handled later.
This reverts commit 08b1bffa49.
Signed-off-by: James Almer <jamrial@gmail.com>
Film grain support adds a huge amount of overhead to the H264Context
structure for a feature that is rarely used. On low end devices or
pages that have lots of media this bloats memory usage rapidly.
This changes the static film grain metadata allocations to be dynamic
which reduces the H264Context size from 851808 bytes to 53444 bytes.
Bug: https://crbug.com/359358875
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Niklas Haas <git@haasn.dev>
The "progress2" API in pthread_slice.c currently associates a progress
value with a thread rather than a job, relying on the broken assumption
that a job's thread number is equal to its job number modulo thread
count.
This removes this API entirely, and changes hevcdec to use a
ThreadProgress-based implementation that associates a
mutex/cond/progress value with every job.
Fixes races and deadlocks in hevdec with slice threading, e.g. some of
those mentioned in #11221.
It can't be higher than vps_max_sub_layers.
Do this while keeping the workaround for qsvenc_hevc calling ff_hevc_parse_sps()
without a vps_list, as in some cases it needs to parse an sps to generate a fake
vps derived from it.
Signed-off-by: James Almer <jamrial@gmail.com>
With multilayer001.heic:
Before:
[hevc @ ...] Scalability type 2 not supported
[hevc @ ...] Ignoring unsupported VPS extension
[hevc @ ...] The following bit-depths are currently specified: 8, 9, 10 and 12 bits, chroma_format_idc is 0, depth is 0
After:
[hevc @ ...] Scalability type 2 not supported
[hevc @ ...] Ignoring unsupported VPS extension
[hevc @ ...] SPS 1 references an unsupported VPS extension. Ignoring
Signed-off-by: James Almer <jamrial@gmail.com>
The per-frame reference picture set contains two more lists -
INTER_LAYER[01]. Assuming at most two layers, INTER_LAYER1 is always
empty, but is added anyway for completeness.
When inter-layer prediction is enabled, INTER_LAYER0 for the
second-layer frame will contain the base-layer frame from the same
access unit, if it exists.
The new lists are then used in per-slice reference picture set
construction as per F.8.3.4 "Decoding process for reference picture
lists construction".
