Fixes: null pointer dereference
Fixes: 471768165/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_DEC_fuzzer-6187504467509248
The first frame allocates buffers with one transform type
the second frame sets up another transform type but the code to reallocate buffers is never triggered
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This removes the internal sample format convert
Fixes: nan is outside the range of representable values of type 'int'
Fixes: 471946097/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LIBVORBIS_DEC_fuzzer-4843605174059008
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
For AV1, NV_ENC_BFRAME_REF_MODE_MIDDLE does not use a single middle
B-frame. Per the NVENC Programming Guide, it sets every other B-frame
as an Altref2 reference except the last B-frame in the Altref interval.
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
I could not find any documentation which disallows the use of transparency for
pixel formats other than YUV 4:2:0, so this patch adds support for transparency
using 4:2:2, 4:4:4, RGB, and their high bit depth variants.
It is not quite clear if the alpha channel should be encoded using the
same pixel format as the normal channels, or it should be always YUV 4:2:0. I
sticked to 4:2:0.
Unfortunately the browsers I tested (chrome, firefox) only support 4:2:0
properly, so let's require an experimental flag to generate files with the new,
more exotic pixel formats.
Signed-off-by: Marton Balint <cus@passwd.hu>
Fixes: out of array access
Fixes: 418335931/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_DEC_fuzzer-6718455383654400
Fixes: 471611870/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_DEC_fuzzer-6645447302381568
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In this case an av_assert2 in lavu/softfloat.h pulls in
a dependency on av_log(), which is not available at all,
because the tablegen tools are created for and run on
the host, not the target. This leads to linking failures.
Fix this by undefining ASSERT_LEVEL before the inclusion
of avassert.h.
Reviewed-by: Timo Rothenpieler <timo@rothenpieler.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: passing zero to __builtin_clz(), which is not a valid argument
Fixes: 471569982/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PRORES_RAW_DEC_fuzzer-5832576221904896
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Priming samples don't depend on the contents of the first frame passed to the
encoder but rather on encoder configuration, so use dummy vorbis_dsp_state and
vorbis_block with the main encoder vorbis_info to generate a packet we can then
parse to derive the initial padding.
Muxers will now be aware of the initial padding before receiving packets, which
will allow them to write proper container headers during init without any extra
considerations like having to do a second pass or rewrite during write_trailer.
Signed-off-by: James Almer <jamrial@gmail.com>
ff_rate_control_init/uninit() are only called during
codec init or close and no DSP calls happen in these,
so there is no need to reset the floating point state.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The MMX code has been removed in 5ef613bcb0
and MMX was not used for most cpus even before then.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This also advertises the supported sample rates/channel layouts.
For ADPCM_IMA_AMV, it actually fixes the advertised channel layouts.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
We know that this is Dolby Vision Enhancement Layer and while it's not
handled, we can just reduce log spam for this, as it's if fact
recognized.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Photoshop documents can contain additional "auxiliary" channels that
don't take part in layer compositing, therefore, using the channel count
to determine the presence of an alpha channel in the merged image is
incorrect. Instead, as per the PSD specification, use the sign of the
layer count (present in the layers and masks section) to determine if
there is an alpha channel, then determine the number of primary channels
using both the presence of the alpha channel and the pixel format.
Already checked via CODEC_SAMPLERATES and CODEC_SAMPLEFMTS.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is pointless for them given that these values will
be overridden by the decoder lateron anyway.
The only exceptions to this are scenarios where the decoder
actually checks request_sample_fmt or where there are both
fixed- and floating point decoders.
(IMO something like get_format() for audio would be better for
both cases.)
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
