Broken in 6e225123d8, because
ff_copy_bits() expects the amount of bits, not bytes to write.
And because it relies on the buffer to be padded, using
side_data->size * 8 is not possible. So partially revert
said commit.
Fixes ticket #11591.
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>
The spec indeed does not allow the aspect ratio to change
within a video sequence, but this does not imply that we
must reinitialize the decoder if only the aspect ratio changes,
as this value does not affect the decoding process at all.
Moreover, our reinitialization is a bit buggy: If there is
frame reordering, then the not yet output next P-frame is
simply discarded upon reinit. With this patch this no longer
happens when only the aspect ratio changes.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The MPEG-1 decoder has an update_thread_context function set,
yet it was never enabled (missing AV_CODEC_CAP_FRAME_THREADS
flag). So remove it and also the ff_thread_finish_setup() call
as well as the progress reporting.
(Simply setting the flag would not be enough. The main problems
are:
a) The update_thread_context function relies on memcpy'ing
the whole context instead of only copying the necessary fields.
This leads to data races which is undefined behaviour.
(Btw: The check for whether the non-MpegEncContext fields
of Mpeg1Context should be copied has been broken in
7f0efe232475d7a704924a3cb308281973e8add3.)
b) Even an AVBufferRef* is simply copied, without creating a new
reference.
c) Copying the whole context happens only during init; when parameters
change lateron, the change is not propagated to the next thread.
This affects at least the quant matrix (for MPEG-1).
d) The MPEG-1/2 decoders are made to decode both MPEG-1 and MPEG-2.
When MPEG-2 is decoded, another complication arises: In case of
coded fields, both fields can be in one AVPacket or they can be
in separate AVPackets. One would need to parse enough of the data
to be able to determine whether the next thread needs to start
a new frame or decode the second field of the current frame;
for this one would need to either postpone calling
ff_thread_finish_setup() for coded slices altogether or implement
some form of ff_h2645_packet_split().
One would also need a second ThreadProgress to signal progress
of each field.
e) One would need to reenable waiting in ff_mpv_reconstruct_mb()
for MPEG-1/2 (and H.261).
f) Probably lots of other stuff for invalid input that I am currently
not thinking about.
If this were done, nothing from the current update_thread_context
would remain, so one can just nuke it altogether.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Call ff_mpeg_update_thread_context() first and
update the RV34 buffers if it indicates a reinitialization.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Namely of reinititialization performed by
ff_mpeg_update_thread_context(), so that they can simply
update their own dimension-based buffers accordingly.
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>
