If AVOptionArrayDef.def is NULL, av_opt_is_set_to_default() should return true
when the field in the object is NULL.
Signed-off-by: James Almer <jamrial@gmail.com>
With the limiting of video usages on the image views, we no longer need
a yuv sampler, since no multi-plane image will be created with the
SAMPLED usage bit.
Lone DPBs will only be requested when the implementation requires
a separate DPB. These images are never given out, and are never used for
anything other than a DPB. Also most implementations requiring these
won't support any other usages on DPBs, so limiting the usages would fix
some validation errors.
Prior to the fix, in the case of a tile containing multiple slices
(pps_num_exp_slices_in_tile != 0) the number of slices was temporarily
allowed to exceed pps_num_slices_in_pic_minus1+1 and therefore
VVC_MAX_SLICES. The number of slices was later verified, but while the
current slice index was higher than expected it was used to write to a
array of size VVC_MAX_SLICES, leading to an OOB write.
To rectify this, the patch adds some checks at an earlier stage, to
ensure that the slice index i + j at no point exceeds
pps_num_slices_in_pic_minus1.
Fixes #YWH-PGM40646-30
Firstly, mathops.h is a private header of libavcodec and should not be used
in fftools. It may reference libavcodec internal symbols, causing link
error with dynamic library, e.g.,
fftools/ffmpeg_filter.c:2687: undefined reference to `ff_rv_zbb_supported'
Secondly, mid_pred operates on int types, while current use case is
int64_t.
Previously, the pkt_size option only affected write buffering in the file
protocol. This change extends its effect to read mode as well.
On embedded systems with limited RAM, users can now reduce I/O buffer
memory by setting a smaller pkt_size.
Signed-off-by: caifan3 <caifan3@xiaomi.com>
The fields are defined as 8 bit long unsigned ints. Fortunately, writing most sane values
as leb is equivalent, which is why no tests are affected.
Signed-off-by: James Almer <jamrial@gmail.com>
The bug was caused by incorrect reading of the step_index field: the original
code read a 16-bit value (including a padding byte) instead of the correct
8-bit step_index as defined by the ADPCM format. This led to distorted audio
or incorrect step calculations when decoding specific ADPCM-encoded files.
Fix by:
1. Reading step_index as an 8-bit unsigned byte via bytestream2_get_byteu()
2. Skipping the subsequent 8-bit padding byte with bytestream2_skip()
The original fix was intended only for sequential mjpeg, but it was also used for progressive
which broke. This commit fixes this regression
Fixes: issue21225
The testcase 6381/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEGLS_fuzzer-5665032743419904 still exits within 240ms
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The doxygen comments were missed as these functions were updated
during review; they don't take separate pointer/length parameters
but use an AVBPrint struct now instead.
Also clarify that ff_make_codec_str doesn't log if the logctx
parameter is NULL.
Several files use values for primaries and transfer characteristics other than
BT709 and IEC_61966 respectively, while still being GBR.
Also always set color_range while at it. It's always coded in the bistream.
Fixes part of #21304.
Signed-off-by: James Almer <jamrial@gmail.com>
MSVC build was failing due to preprocessor directives being used within function-like macro argument lists, which is undefined behavior according to the C11 spec. Fixed by replacing the directive blocks with macro definitions outside of the macro invocations.
A layer could define a loudspeaker_layout that corresponds to a certain channel layout,
but then report an amount of substream_count and coupled_substream_count that might not
match the expected channel count.
Fixes: Invalid write of size 4
Fixes: clusterfuzz-testcase-minimized-ffmpeg_dem_IAMF_fuzzer-6687125346254848
Signed-off-by: James Almer <jamrial@gmail.com>
The semantics of sh_num_ref_idx_active_minus1[ i ] state that
When the current slice is a P slice, the value of NumRefIdxActive[ 0 ] shall be greater than 0.
When the current slice is a B slice, both NumRefIdxActive[ 0 ] and NumRefIdxActive[ 1 ] shall be greater than 0.
Fixes: use of uninitialized memory
Fixes: 449549597/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VVC_fuzzer-5600497089445888
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reported-by: Michael Niedermayer michael@niedermayer.cc
The current logic implicitly pulled the new value range out of SwsComps using
ff_sws_apply_op_q(), but this was quite ill-formed and not very robust. In
particular, it only worked because of the implicit assumption that the value
range was always set to 0b1111...111.
This actually poses a serious problem for 32-bit packed formats, whose
value range actually does not fit into AVRational. In the past, it only
worked because the value would implicitly overflow to -1, which SWS_OP_UNPACK
would then correctly extract the bits out from again.
In general, it's cleaner (and sufficient) to just explicitly reset the value
range on SWS_OP_UNPACK again.
The current behavior of assuming the value range implicitly on SWS_OP_READ
has a number of serious drawbacks and shortcomings:
- It ignored the effects of SWS_OP_RSHIFT, such as for p010 and related
MSB-aligned formats. (This is actually a bug)
- It adds a needless dependency on the "purely informative" src/dst fields
inside SwsOpList.
- It is difficult to reason about when acted upon by SWS_OP_SWAP_BYTES, and
the existing hack of simply ignoring SWAP_BYTES on the value range is not
a very good solution here.
Instead, we need a more principled way for the op list generating code
to communicate extra metadata about the operations read to the optimizer.
I think the simplest way of doing this is to allow the SwsComps field attached
to SWS_OP_READ to carry additional, user-provided information about the values
read.
This requires changing ff_sws_op_list_update_comps() slightly to not completely
overwrite SwsComps on SWS_OP_READ, but instead merge the implicit information
with the explictly provided one.
I think this is ultimately a better home, since the semantics of this are
not really tied to optimization itself; and because I want to make it an
explicitly suported part of the user-facing API (rather than just an
internal-use field).
The secondary motivating reason here is that I intend to use internal
helpers of `ops.c` inside the next commit. (Though this is a weak reason
on its own, and not sufficient to justify this move by itself.)
Fixes: call to function handle_rendition_args through pointer to incorrect function type 'void (*)(void *, const char *, int, char **, int *)'
Fixes: 464965411/clusterfuzz-testcase-minimized-ffmpeg_dem_HLS_fuzzer-4790164406992896
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
