The majority of the stuff performed in it needs to be done only
once; so factor it out into a function of its own to be called
in the user's init function.
Also avoid using MpegEncContext in it, to separate the two
a bit more.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Not all compare functions are implemented for all compare function
types. Therefore check for the existence of the used functions.
Fixes issue #10245.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Possible by using MB_TYPE_CODEC_SPECIFIC for MB_TYPE_ZERO_MV
and due to the MB_TYPE_*_MV flags fitting into an int16_t.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Possible now that MB_TYPE_L1 (which does not fit into
an int16_t) is no longer used).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
MB_TYPE_L[01] is based upon H.264 terminology (it stands for
list); yet the mpegvideo based decoders don't have lists
of reference frames, they have at most one forward and one
backward reference. So use terminology based upon this.
This also has a second advantage: MB_TYPE_L[01] is actually
an OR of two flags (which are set independently for H.264,
but aren't for mpegvideo). Switching to different flags
makes the flags fit into an int16_t, which will be useful
in future commits.
The only downside to this is a very small amount of code
in error_resilience.c and mpegutils.c (the only code shared
between the H.264 decoder and mpegvideo).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The "invalid mtype index" here is always -1, because that is
the value the VLC api uses for not existent leafs in an incomplete tree.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible now that MB_TYPE_CBP and MB_TYPE_QUANT
fit into an int16_t; only MB_TYPE_H261_FIL needs to
be remapped to MB_TYPE_CODEC_SPECIFIC.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Do this to make MB_TYPE_{CBP,QUANT} fit into an int16_t,
so that can be used in a VLC symbol table.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
MB_TYPE_ACPRED is currently reused for MB_TYPE_REF0 by H.264,
so that the value fits into an uint16_t. Given that MB_TYPE_ACPRED
is not subject to any such restriction (apart from fitting into
32bits), it can be remapped to a hithereto unused bit.
The then available bit will be declared to be codec-specific
(i.e. unused by generic code), so that H.264 can use it
for MB_TYPE_REF0 and so that it can be reused later for
e.g. MB_TYPE_H261_FIL.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Set them in ff_mpv_idct_init() so that they are already set
in ff_mpv_decode_init(). This is in preparation for avoiding
to set dct_unquantize in every ff_mpv_frame_start().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When the SPS associated with a particular SPS ID changes, invalidate all
the PPSs which use that SPS ID. Fixes crashes with illegal bitstreams.
This is done in the CBS, rather than in libavcodec/vvc/ps.c like the SPS
ID reuse validation, as parts of the CBS parsing process for PPSs
depend on the SPS being referred to.
Signed-off-by: Frank Plowman <post@frankplowman.com>
This or fifo needs to be freed on errors explicitly
Fixes: memleak
Fixes: 68937/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LIBVPX_VP8_fuzzer-4830831016214528
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: James Zern <jzern@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is used by future versions of the spec to implement metadata
compression. Given that we don't yet implement that spec, validate that
this is equal to 0 for now.
Despite the suggestive size limits, this metadata ID has nothing to do
with the VDR metadata ID used for the data mappings. Actually, the
specification leaves them wholly unexplained, other than acknowleding
their existence. Must be some secret dolby sauce. They're not even
involved in DM metadata compression, which is handled using an entirely
separate ID.
That leaves us with a lack of anything sensible to do with these IDs.
Since we unfortunately only expose one `dm_metadata_id` field to the
user, just ensure that they match; which appears to always be the case
in practice. If somebody ever hits this error, I would really much
rather like to see the triggering file.
When this is 0, the metadata is explicitly inferred to stated default
values from the spec, rather than inferred from the previous frame's
values.
Likewise, when encoding, instead of checking if the value changed since
the last frame, we need to check if it differs from the default.
According to the spec, missing previous VDR RPU IDs do not constitute an
error, but we should instead fallback first to VDR RPU with ID 0, and
failing that, synthesize "neutral" metadata.
That's nontrivial though as the resulting metadata will be dependent on
other properties of the RPU, and this case is not hit in practice so
I'll defer it to a rainy day.
The SEI handling of libx265 is buggy and can easily lead
to memory corruption: It reuses certain buffers, but when
reusing them it presumes that it is enough for these buffers
to exist and does not check whether they are actually large
enough to hold what is intended to be stored in them.*
Our users are exposed to this because forwarding A53 CC data
is enabled by default. Change this to make it disabled
by default.
"Fixes" tickets #10411, #11052 and (presumably) #10906.
*: See https://trac.ffmpeg.org/ticket/9666#comment:1
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Add external encoder VVenC for H266/VVC encoding.
Register new encoder libvvenc.
Add libvvenc to wrap the vvenc interface.
libvvenc implements encoder option: preset,qp,qpa,period,
passlogfile,stats,vvenc-params,level,tier.
Enable encoder by adding --enable-libvvenc in configure step.
Co-authored-by: Christian Bartnik chris10317h5@gmail.com
Signed-off-by: Thomas Siedel <thomas.ff@spin-digital.com>
The vendor has long since switched to Arm, with the last product
reaching their official end-of-life over 11 years ago. Linux support for
the ISA was dropped 7 years ago. More importantly, this architecture was
never supported by upstream GCC, and the vendor fork is stuck at version
4.2, which FFmpeg no longer supports (as per C11 requirement).
Presumably, this is still the case given the lack of vendor support.
Indeed all of the code being removed here consisted of inline assembler
scalar optimisations. A sane C compiler should be able to perform those
automatically nowadays (with the sole exception of fast CLZ detection),
but this is moot as this architecture is evidently dead.
The code as written was wrong. In the spec, these fields are treated
merely as plain integers in the range 0 to 4095. The only difference
between L2 and L8 is that L2.ms_weight also accepts an additional value
of -1, hence the extra sign bit. While it's likely that these are still
shifted integers in disguise, since all real-world samples seem to use
a value of 2048 here, the offset used in the code was wrong.
In addition, because the l8.ms_weight struct member is unsigned, these
wrong shifting semantics ended up overflowing the field, leading to
undefined behavior when transcoding. Fortunately, the damage was
relatively contained in practice, because it just corrupts the coding of
this field, which is ignored in practice in all implementations I have
seen.
Introduced in 1992, the Alpha was a 64-bit RISC processor designed
to replace the VAX CISC machines sold by Digital Equipment Corporation.
After Digital was acquired by Compaq in 1998 -- who themselves would be
later purchased by Hewlett-Packard, the architecture was phased out over
the following decade. It became effectively defunct in 2007, the last
publicly available processor being the Alpha 21364.
FFmpeg has not added any DSP code for this architecture since lowres2
was introduced in 2012, and it is more than unlikely someone still wishes
to maintain it.
Remove the DSP and support code.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Support for SuperH was dropped over a decade ago. There no longer is any
architecture-specific code to be found, so just remove the corresponding
test. Technically it is still possible to compile FFmpeg as the
"generic" (pure C) architecture.
Currently it is only done if the final CTB address is at the end of the
frame, however that address is not known with hwaccel decoding. As we
only support exactly one AU per packet, and not partial/multiple AUs, we
can just as well call hevc_frame_end() unconditionally.
Fixes hwaccel decoding after d725c737fe.
Reported-by: llyyr <llyyr.public@gmail.com>
On the top of p. 112 in VVC (09/2023):
It is a requirement of bitstream conformance that the values of
qpInVal[ i ][ j ] and qpOutVal[ i ][ j ] shall be in the range
of −QpBdOffset to 63, inclusive for i in the range of 0 to
numQpTables − 1, inclusive, and j in the range of 0 to
sps_num_points_in_qp_table_minus1[ i ] + 1, inclusive.
Additionally, don't discard the return code from sps_chroma_qp_table.
Signed-off-by: Frank Plowman <post@frankplowman.com>
It has been added in 3a87ac948f,
but there was never an implementation different from the ordinary
dct_quantize of it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Use the common approach whereby the _c versions are set first
and then (potentially) overwritten by the arch-specific ones
instead of calling the arch-specific code first, followed by
setting the function pointers that have not already been set.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Andreas Rheinhardt
Frank Plowman
Araz Iusubov
Michael Niedermayer
Niklas Haas
Osamu Watanabe
Thomas Siedel
Rémi Denis-Courmont
James Almer
Sean McGovern
Anton Khirnov
sunyuechi