Instead add the necessary blocks directly into Mpeg12SliceContext.
This allows to completely remove MPVContext.block.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Add a GetBitContext to H263DecContext instead. This is in preparation
for removing MpegEncContext.gb.
Also move last_resync_gb to H263DecContext.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Instead add the necessary blocks directly to H263DecContext
(only six are needed, not 12 as ff_mpv_common_init()
currently allocates).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
With the exception of mpeg4_decode_studio_mb(), all decode_mb
functions implicitly presumed that the block provided as
argument coincides with MpegEncContext.block (they zeroed the latter
and then used the former to decode the block); mpeg4_decode_studio_mb()
meanwhile did not use the provided block at all (it uses blocks of
int32_t). So remove said parameter.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is in preparation for moving the fields only used
by H.263-based decoders from MPVContext to H263DecContext.
For now only the decode_mb function pointer has been moved
(to be able to switch said callback to use an H263DecContext*).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The code in h263dec.c is not supposed to know that the MPEG-4
decoder uses an Mpeg4DecContext as private context at all
(said context is only exposed in a header so that hardware
accelerations can access it and for the parser to use).
Passing an MPVContext* directly also allows to remove
the indirection via AVCodecContext.priv_data.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This basically reverts d4967c04e0.
Said commit was based on the false premise that it would
be an aliasing violation to upcast a pointer to structure
to a pointer to a bigger structure containing the original
structure as its first element, but this is just not true.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This avoids mpegvideo.c having to deal with the fact that
the encoders use two sets of blocks and is in preparation
for not allocating blocks at all.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The H.263 decoder itself does not need max_run/max_level
of this RLTable, only the MPEG-4 decoder does.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Only used by the decoder now that the encoder solves
out-of-slice predictions by setting the out-of-slice
values appropriately.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The chroma dc_val pointers are mostly unused (accesses use
dc_val[0] and block_index), so remove them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
All callers check the corresponding entry of MpegEncContext.mbintra_table
and if set (indicating that the intra tables might have been written to
when decodeing a intra MB, so that they are "dirty"), call
ff_clean_intra_table_entries(), which resets them to default values
and resets the mbintra_table entry. Move resetting to the callers
(via an inline function that also performs the checks). This currently
has the advantage that the additional load of the mbintra_table ptr
can be avoided. It will also allow to simplify
ff_clean_intra_table_entries() (by using block_index[4] and [5]).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Just ensure that dct_unquantize_inter is set iff it is used
and check for the function pointer instead.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is unnecessary: If the dst context is not already initialized,
then it will be initialized by memcpy(dst, src, sizeof(*dst),
which already initializes the IDCT to the desired one, potentially
followed by ff_mpv_common_init(), which does not touch the IDCT.
(This call has been added in f89d76c103;
the aforementioned copying took place back then, too, but
ff_mpv_common_init() reinitialized the IDCT to a non-xvid one,
therefore the initialization here has been added to fix
multithreaded decoding.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The MPEG-4 decoder can now initialize ff_mpeg4_rl_intra
directly given that the MPEG-4 encoder no longer wants
it performed, too.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The reversible VLC tables use a simpler escaping method
than the ordinary VLCs: It does not use max_run, max_level etc.
and therefore one does not need to initialize these at all.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Only the studio profile uses chroma_inter/intra matrices;
the ordinary profile has only inter/intra matrices.
And our code (namely the MPEG-2 unquantize functions)
only use these two matrices (the MPEG-2 decoder unquantizes
on its own while parsing).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There is only one source of dirty MpegEncContexts:
update_mpvctx() (which copies an MpegEncContext
over another one in order to initialize it). So only clear
these contexts.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When the destination MpegEncContext in ff_mpeg_update_thread_context()
is not initialized, the source MpegEncContext is simply copied
over it before (potentially) calling ff_mpv_common_init().
This leads to data races when this code is executed which is why
it should be replaced with only copying the necessary fields
(this is for future commits).
Given that the RV30 and RV40 decoders always call said function
with an already initialized MpegEncContext (they use context_reinit
in case of frame size changes), they don't need this ugly
initialization (and are therefore race-free). This means that
this code can be moved to the only decoder that actually needs it:
MPEG-4. This commit does so.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is only used by the MPEG-4 decoder and the encoders.
Notice that this field is a per-frame property and therefore
does not need to by synced in mpeg4_update_thread_context().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Namely in ff_mpeg4_get_video_packet_prefix_length().
This will allow to move [fb]_code from MpegEncContext.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When switching to the XviD IDCT, the IDCT permutation can change.
Given that we already permute the quant matrices when parsing
them, they need to be permuted, too. Up until now this has not been
done; instead the header has been parsed again in the expectation
that the currently active quant matrix is contained in this header.
This expectation is wrong; it is for example wrong when the VOL
header is only available via extradata (such a file can be easily
created from xvid_vlc_trac7411.h263 (in the FATE suite) via the
remove_extra BSF). It could also be wrong if the XviD user data
is only available in a subsequent packet.
This commit therefore switches to permuting the relevant matrices
directly. It also stops parsing the header a second time
when switching to the XviD IDCT.
(I wonder whether ff_mpv_idct_init() should take alternate_scan
into account when initializing permutated_intra_h_scantable
as the decoder does. Does the MPEG-4 encoder use a wrong scantable
in this case?)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It does not change lateron.
(If we were to add short header support later, it would involve
a branch in mpeg4_decode_block() anyway and we would then
hardcode the dc_scaler value of eight there; the *_scale_tables
would stay the same.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
For all encoders and all decoders except MPEG-4 the unquantize
functions to use don't change at all and therefore needn't be
kept in the context. So discard them after setting them;
for MPEG-4, the functions get assigned on a per-frame basis.
Decoders not using any unquantize functions (H.261, MPEG-1/2)
as well as decoders that only call ff_mpv_reconstruct_mb()
through error resilience (RV30/40, the VC-1 family) don't have
the remaining pointers set at all.
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>
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>
It is only used by MPEG-4 (and is used in h263dec.c and can therefore
not just be moved to Mpeg4DecContext...).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is an MPEG-4-only value; it is always five for the MPEG-4
encoder, so just hardcode this value and move the MpegEncContext
field to Mpeg4DecContext.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
inter_scantable is only used by the dct_unquantize_h263_inter
functions, yet this is not used by the MPEG-4 decoder at all
(in case H.263 quantization is used, the unquantization already
happens in mpeg4_decode_block()).
Also move the common initialization of ff_permute_scantable()
out of the if.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
All valid values of dc_lum and dc_chrom are in the range 0..9,
because they are initialized via tables with 10 elements.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
