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>
The C version is set in ff_dct_encode_init(), yet the MIPS version
is set in dct_init() (in ff_mpv_common_init() and therefore also
for decoders). This commit fixes this inconsistency.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The H.264 decoder used reference to store its picture_structure
into it; yet it does not use mpegvideo any more since commit
2c54155407. Afterwards commit
629259bdb5 removed the last remnants.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It has been added in a579db0c4f
due to XvMC, but today it is only used to swap U and V
for VCR2, a MPEG-2 variant with U and V swapped.
This can be done in a simpler fashion, namely by simply
swapping the U and V pointers of the corresponding
MPVWorkPictures.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
MPEG-1/2 only needs one scantable and therefore all code
already uses the intra one. So stop initializing
the inter one altogether.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The days in which an MPVPicture* is set with the corresponding frame
being blank are over; this allows to simplify some checks.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This also rids us of the requirement to preserve the PutBitContext
in ff_update_duplicate_context().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Only set the ScratchpadContext and let the users that need it
(i.e. encoders) set the MotionEstContext stuff themselves.
Also add an explicit pointer to ScratchpadContext to point
to the allocated buffer so that none of the other scratchpad
pointers is singled out as being used for the allocations.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These pointers point to the same buffers, so one can just
use a union for them and avoid synchronising one of them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Given that MPVPictures are already directly shared between threads
in case of frame-threaded decoding, one can simply use it to
pass decoding progress information between threads. This allows
to avoid one level of indirection; it also means avoids allocations
(of the ThreadFrameProgress structure) in case of frame-threading
and indeed makes ff_thread_release_ext_buffer() decoder-only
(actually, H.264-decoder-only).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, an initialized MpegEncContext had an array of
MPVPictures (way more than were ever needed) and the MPVPicture*
contained in the MPVWorkPictures as well as the input_picture
and reordered_input_picture arrays (for the encoder) pointed
into this array. Several of the pointers could point to the
same slot and because there was no reference counting involved,
one had to check for aliasing before unreferencing.
Furthermore, given that these pointers were not ownership pointers
the pointers were often simply reset without unreferencing
the slot (happened e.g. for the RV30 and RV40 decoders) or
there were moved without resetting the src pointer (happened
for the encoders where the entries in the input_picture
and reordered_input_picture arrays were not reset).
Instead actually releasing these pictures was performed by looping
over the whole array and checking which one of the entries needed
to be kept. Given that the array had way too many slots (36),
this meant that more than 30 MPVPictures have been unnecessarily
unreferenced in every ff_mpv_frame_start(); something similar
happened for the encoder.
This commit changes this by making the MPVPictures refcounted
via the RefStruct API. The MPVPictures itself are part of a pool
so that this does not entail constant allocations; instead,
the amount of allocations actually goes down, because the
earlier code used such a large array of MPVPictures (36 entries) and
allocated an AVFrame for every one of these on every
ff_mpv_common_init(). In fact, the pool is only freed when closing
the codec, so that reinitializations don't lead to new allocations
(this avoids having to sync the pool in update_thread_context).
Making MPVPictures refcounted also has another key benefit:
It makes it possible to directly share them across threads
(when using frame-threaded decoding), eliminating ugly code
with underlying av_frame_ref()'s; sharing these pictures
can't fail any more.
The pool is allocated in ff_mpv_decode_init() for decoders,
which therefore can fail now. This and the fact that the pool
is not unreferenced in ff_mpv_common_end() also necessitated
to mark several mpegvideo-decoders with the FF_CODEC_CAP_INIT_CLEANUP
flag.
*: This also means that there is no good reason any more for
ff_mpv_common_frame_size_change() to exist.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Currently identical to the H.261 and H.263 close functions
(which it replaces). It will be extended in future commits.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is all that is used. This is in preparation for further
commits that will extend ff_mpv_decode_init() in a way
that will make it possible to fail and require cleanup.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It already avoids a goto and will be useful in the future
to be able to specify each functions tasks and obligations.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
