Used with trellis; notice that inter_matrix is unused for
(intra-only) SpeedHQ, so it is irrelevant that its value changes.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also start factoring the matrix-init code out into a function
of its own to declutter ff_mpv_encode_init().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It currently does two things: a) Get a prediction for the dc
and the dc direction and b) process said prediction. Processing
the prediction differs for encoding (getting a diff) and decoding
(getting the level via diff+prediction). So having a common function
performing b) makes no sense.
Even worse, there is a decoding mode where the dc coefficient (diff)
is not coded specially and therefore unavailable before entering
the block decoding loop, so that one can only perform a). Before
this commit, the decoder simply called ff_mpeg4_pred_dc() twice;
the results of the b) part of the call before the loop were ignored
(but the compiler could not elide them because they involved error
messages) and a) was also performed twice.
This commit changes this by splitting b) out of ff_mpeg4_pred_dc()
and moving this code to decoder and encoder.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The scantables are unused for the parser (and in fact
the IDCT permutation used has not been initialized at all).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(To perform this optimization a compiler would have to look
at both ff_rv_decode_dc() and av_log(). The latter seems very
unlikely.)
Reviewed-by: Ramiro Polla <ramiro.polla@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
h263_aic is always zero for FLV and ff_mpeg1_dc_scale_table
is already the default dc_scale table for both y and c.
h263_aic is also always zero for the FLV decoder.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
They only do it for the mv_penalty table. Factor initializating
the static tables out into a function of its own; also move
everything not needed by SVQ1 or Snow behind #if CONFIG_H263_ENCODER
(this involved moving ff_h263_encode_motion() which is used
by svq1enc).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
MPEG-1/2 and the H.263-based encoders overwrite the default later
and SpeedHQ and MJPEG-based encoders are intra-only and don't
need a mv_penalty table at all. So only H.261 uses this table.
Also add a comment to explain why it exists and is non-const.
Reviewed-by: Ramiro Polla <ramiro.polla@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Compilers can not perform this optimization on their own
given that they don't know that the different thread_context
pointers don't alias.
Also avoid using sequentially consistent operations with
atomics when only a single thread accesses them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The VC-1 decoders don't need ScanTable.raster_end as
they don't call any of the unquantize functions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, it only returned the number of bits for the
start offset, but not the start offset; the GetBitContext
passed to it was unused.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It's not possible to put USAC into ADTS due to exceeding the
field size (4 bits) for ADTS profile. As such cases where
the frame starts with 0xfff shouldn't be checked.
This ensures the sample at https://crbug.com/396190942 is
properly detected as USAC content.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Storing the values via a union of an uint32_t and a float makes
said union the effective type of the destination. This means that
it may only be read via such a union which is of course not what
our users do/expect. So store the values via AV_WN32A instead
which disables effective type analysis (for compilers that perform it).
This also fixes a -Wdeclaration-after-statement warning
introduced in 0e917389fe.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Otherwise compilers might emit code that presumes there to be
a GOT which can't be fixed by the linker.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is inspired by the equivalent dav1d attribute introduced
by Henrik Gramner in e4c4af02f3de5e6cea6f81272a2981c0fa7bae28.
Also already use it to beautify declarations.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When used with the "mpegvideo" or "mpeg1video" decoder (which do not
have a private class) this would lead to the log callback receiving
a non-NULL object with a NULL AVClass pointer. The default log callback
handles this gracefully, yet it is probably an API violation.
Reviewed-by: Ramiro Polla <ramiro.polla@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, the initialization of AMV's matrices happened
after the initialization for MJPEG matrices, overwriting
the earlier data. This commit changes this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible because the packet is reference-counted
and because we never combine the data from several packets.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible by moving the code using it to open a GetBitContext
from h263dec.c to mpeg4videodec.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
All hwaccels for MPEG-4/H.263 are run serially even when frame-threading
is in use. Therefore there is no gain in calling
ff_thread_finish_setup() in this case right before outputting
the frame.
Removing this call also allows to revert commit
39a5c0ac06.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
