Signed-off-by: James Almer <jamrial@gmail.com>

It's more descriptive of what it does.
Signed-off-by: James Almer <jamrial@gmail.com>

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 f64c2e71 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.)

Fixes valgrind warnings after 18adaf9f.
Signed-off-by: James Almer <jamrial@gmail.com>

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 d725c737.
Reported-by: llyyr <llyyr.public@gmail.com>

The 2 links are the clearest i found.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Marton Balint <cus@passwd.hu>

Signed-off-by: Marton Balint <cus@passwd.hu>

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>

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

Since len < 64, the registers are sufficient, so it can be
directly unrolled (a4 is even).

Another benefit of unrolling is that it reduces one load operation
vertically compared to horizontally.

                                 old                 new
                             C908   X60          C908   X60
vp8_put_bilin4_h_c         :    6.2    5.5     :    6.2    5.5
vp8_put_bilin4_h_rvv_i32   :    2.2    2.0     :    1.5    1.5
vp8_put_bilin4_v_c         :    6.5    5.7     :    6.2    5.7
vp8_put_bilin4_v_rvv_i32   :    2.2    2.0     :    1.2    1.5
vp8_put_bilin8_h_c         :   24.2   21.5     :   24.2   21.5
vp8_put_bilin8_h_rvv_i32   :    5.2    4.7     :    3.5    3.5
vp8_put_bilin8_v_c         :   24.5   21.7     :   24.5   21.7
vp8_put_bilin8_v_rvv_i32   :    5.2    4.7     :    3.5    3.2
vp8_put_bilin16_h_c        :   48.0   42.7     :   48.0   42.7
vp8_put_bilin16_h_rvv_i32  :    5.7    5.0     :    5.2    4.5
vp8_put_bilin16_v_c        :   48.2   43.0     :   48.2   42.7
vp8_put_bilin16_v_rvv_i32  :    5.7    5.2     :    4.5    4.2
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

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>

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.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>

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

It has been added in 3a87ac94,
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>

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Only used here.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Always false since 49331f7b.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Forgotten after 41f97420.
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
2c541554. Afterwards commit
629259bd removed the last remnants.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

It is redundant due to the identical check in ff_mpv_encode_init().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Improves readability.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

It has been added in a579db0c
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>

Avoids a cast.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

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>

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>

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>