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.
C code or compiler built-ins are preferable over inline assembler for
byte-swaps as it allows for better optimisations (e.g. instruction
scheduling) which would otherwise be impossible.
As with f64c2e710f for x86 and Arm,
this removes the inline assembler on GCC (and Clang) since we now
require recent enough compiler versions. This indeed seems to work on
AArch64, SuperH and, if Zbb is enabled, RISC-V. (AVR32 was not tested
since it has no known working compilers at this time.)
Since the C11 support is required, those GCC versions can no longer be
supported anyhow. (Clang pretends to be GCC 4.4, but it looks like the
code was intended for old GCC specifically.)
Since the C11 support is required, those GCC versions can no longer be
supported anyhow. (Clang pretends to be GCC 4.4, but the removed code
does not seem to have been intended for Clang.)
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>
Also make the iso_channel_position table consistent with what the AAC decoder
uses in avcodec/aac/aacdec_usac.c.
Fate changes are caused by the change of how 7.1 layout is mapped, previously
it included Side Surround channels, now it includes the Surround channels.
Signed-off-by: Marton Balint <cus@passwd.hu>
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>
Besides being write only it had the wrong type:
An uint8_t is definitely not enough to store the size
of these buffers.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.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>
