With the exception of mpeg4_decode_studio_mb(), all decode_mb
functions implicitly presumed that the block provided as
argument coincides with MpegEncContext.block (they zeroed the latter
and then used the former to decode the block); mpeg4_decode_studio_mb()
meanwhile did not use the provided block at all (it uses blocks of
int32_t). So remove said parameter.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is in preparation for moving the fields only used
by H.263-based decoders from MPVContext to H263DecContext.
For now only the decode_mb function pointer has been moved
(to be able to switch said callback to use an H263DecContext*).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The code in h263dec.c is not supposed to know that the MPEG-4
decoder uses an Mpeg4DecContext as private context at all
(said context is only exposed in a header so that hardware
accelerations can access it and for the parser to use).
Passing an MPVContext* directly also allows to remove
the indirection via AVCodecContext.priv_data.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This basically reverts d4967c04e0.
Said commit was based on the false premise that it would
be an aliasing violation to upcast a pointer to structure
to a pointer to a bigger structure containing the original
structure as its first element, but this is just not true.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Instead add the necessary blocks directly to VC1Context
(only six are needed, not 12 as ff_mpv_common_init()
currently allocates).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Add a GetBitContext to VC1Context instead. This is in preparation
for removing MpegEncContext.gb.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These decoders only need a single 4x4 block; put it in RV34DecContext.
This is in preparation for removing MpegEncContext.block.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Instead put it into H261DecContext. This is in preparation
for removing MpegEncContext.block.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In the common case of decoding 420 content, only six blocks are used
and it makes perfect sense for the caller to only have that many.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is unused (because unquantizing/the idct has been disabled)
apart from FF_DEBUG_DCT_COEFF debug code which makes no sense
when this function is called via error resilience. So pass a NULL
as block when calling ff_mpv_reconstruct_mb() from mpeg_er_decode_mb()
and disable the debug code in this scenario.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This allows to hint to the compiler that the branch is likely
not taken by marking the factored out function as av_cold.
It is also in preparation for further commits.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
MpegEncContext is also used for decoding, so it is a misnomer.
This commit therefore adds MPVContext as typedef for it in order
to gradually switch the code to the new name (in line with
MPVEncContext).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This avoids mpegvideo.c having to deal with the fact that
the encoders use two sets of blocks and is in preparation
for not allocating blocks at all.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The H.263 decoder itself does not need max_run/max_level
of this RLTable, only the MPEG-4 decoder does.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Only very few combinations (2x102) of 16384 correspond to
valid codes; so just initialize all codes via memset
and then set the few valid codes explicitly instead of initializing
everything in the same way.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Already checked generically as none of the codecs here
have the AV_CODEC_CAP_CHANNEL_CONF set.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
None of the codecs used here has the AV_CODEC_CAP_CHANNEL_CONF
cap set, so the sample rate is checked generically.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Check that all audio codecs except decoders with the
AV_CODEC_CAP_CHANNEL_CONF flag have a positive sample rate set.
Fixes: AVERROR_BUG return
Fixes: 413997604/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HCA_fuzzer-5188382613635072
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Before this patch, the DFPWM1a encoder was marked as supporting
variable frame sizes. The DFPWM1a format converts eight bytes
of input into one output byte and so it simply padded the number
of data output by
frame->nb_samples * frame->ch_layout.nb_channels / 8 +
(frame->nb_samples % 8 > 0 ? 1 : 0)
This has several bugs:
a) The additional byte leads to eight additional input byte being
read; this can read into the frame's padding, i.e. the data can
be uninitialized.
b) The criterion for whether one should pad is wrong:
nb_samples * nb_channels should be tested for divisibility by eight.
c) The created frames can be undecodable (at least with our decoder):
Our decoder requires the number of bits per frame to divisible by
the number of channels, yet the above approach does not guarantee this.
d) The padding will be added in the middle of the stream (potentially
for every packet).
This commit fixes all of this by removing the variable frame size cap
and using AVCodecInternal.pad_samples to pad the last frame so that
nb_samples * nb_channels is always a multiple of eight.
The lavf-dfpwm FATE-test was affected by a). The frames originated from
lavfi and were part of an audio frame pool, so that the padding
contained data from an earlier (bigger) frame. Now the last frame is
properly filled with silence.
Reported-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Use av_frame_replace() instead. Also remove the error message:
It was highly misleading (as if av_frame_clone() duplicated
the AVFrame data buffers instead of just creating a new reference).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Calling a function via a different function pointer type is
undefined behavior (C11, 6.3.2.3 8); two pointer parameters
of different type are not equivalent in this regard, although
it happens to work in practice; the current code relies on this.
This patch brings the code in line with the spec. This fixes the
following FATE-tests when run with Clang-UBSan:
ac3-fixed-encode-2 audiomatch-afconvert-{16000,44100}-mono-he-{adts,m4a}
audiomatch-dolby-44100-mono-he-mp4 filter-metadata-avf-aphase-meter-mono
filter-pan-{downmix1,downmix2,mono2,stereo2,stereo3,stereo4,upmix1,upmix2}
lavf-dv_{pal,ntsc} matroska-encoding-delay
The error was something like
src/libswresample/rematrix.c:621:17: runtime error: call to function sum2_float through pointer to incorrect function type 'void (*)(void *, const void *, const void *, void *, int, int, int)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes the following FATE-tests when run under Clang-UBSan:
ffmpeg-loopback-decoding, lavf-mxf_ffv1,
vsynth{1,2,3,_lena}-ffv1-v{0,2}, vsynth1-ffv{1,2,3,_lena},
vsynth{1,2,3,_lena}-ffv1-v3-yuv{420p,422p10,444p16}
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes the following error when running with Clang-UBSan:
src/libavcodec/indeo3.c:556:26: runtime error: applying non-zero offset 2560 to null pointer
This fixes the indeo3-2 FATE test.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Added support for MV-HEVC encoding for stereoscopic videos (2 views
only). Compatible with the framepack filter when using the
AV_STEREO3D_FRAMESEQUENCE format.
Signed-off-by: Diego de Souza <ddesouza@nvidia.com>
