This commit adds a reference to the buffer as an argument to
start_frame, and adapts all existing code.
This allows for asynchronous hardware accelerators to skip
copying packet data by referencing it.
Nothing in this decoder would break if the generic code were to be
changed to allow slice "threading" with only one thread.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes undefined integer overflows. The overflows could always
happen, yet before 4d8b706b1d
it was not undefined because the code implicitly used atomic
types, for which signed integer overflow is defined.
Reported-by: Kacper Michajlow <kasper93@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>
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>
The MPEG-1/2 decoders don't need ScanTable.raster_end
(as the coefficients are unquantized as they are parsed).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This decoder unquantizes while parsing blocks
and does not use dct_unquantize_mpeg1_intra
(which uses *_dc_scale) at all.
repeat_field was unused since
e0a3d744a0.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Only the MPEG-1/2, MSMPEG4V1, MPEG-4 and RV.10 decoders use last_dc
at all. Of these, RV.10 only uses it for intra frames; it does not
need these predictors reset in ff_mpv_reconstruct_mb(). MSMPEG4V1
has h263_pred set, so that last_dc is already not reset in
ff_mpv_reconstruct_mb() (instead it is reset at the beginning
of every line). MPEG-4 also has h263_pred set (and uses last_dc only
for the intra-only studio profile and needs them reset to sligthly
different values anyway).
So only the MPEG-1/2 decoders need these values reset. So move
resetting them there. This avoids resetting them unnecessarily
for FLV1, H.261, H.263I, RV.10, RV.20 and H.263(+)
(for the latter it depends upon whether h263_aic is in use).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The format is used by at least Dish Network, but is not
defined in any DVB standard, so remove references to DVB.
This is a simple rename, no functional change.
Signed-off-by: Marth64 <marth64@proxyid.net>
In mpeg_decode_a53_cc() only the A/53 part 4 CC data ("GA94") is saved between
frames. The other formats incorrectly created a larger buffer than they use
since a705bcd763 because they did not append to
the previous data.
The a53_buf_ref is added to the frame in mpeg_field_start() which will only be
called in decode_chunks() if not all of the picture data slices are skipped.
For these formats, utilize the data added to the buffer in case frames are skipped
(concatenating the CC data until a frame can be exported), in a similar fashion to
the A/53 part 4 logic.
Reviewed-by: Marth64 <marth64@proxyid.net>
Signed-off-by: Marth64 <marth64@proxyid.net>
After support was added for DVB 0502 Closed Caption coding,
the cc_format option's range was never updated so user
cannot select this coding as a forced formatting choice.
Fix the range of the option by ending it with the new coding type.
Signed-off-by: Marth64 <marth64@proxyid.net>
These properties are unreliable because they depend on the frames decoded so
far, users should check directly the presence of the decoded AVFrame side data
or AVFrame flags.
Signed-off-by: Marton Balint <cus@passwd.hu>
When Closed Captions are discovered, this method is always invoked.
Therefore, use it to set the property instead of repeating the statement.
Signed-off-by: Marth64 <marth64@proxyid.net>
These values are not read anywhere. Furthermore, since commit
fe6037fd04 the linesize values
of the MPVWorkPictures were wrong for subsequent fields
in a chain of B-pictures (as they are always doubled and no longer
based upon the frame-linesizes) which can eventually lead to overflow.
Finally, it makes no real sense to ever double the linesize
of the reference pictures at all: Even when the current picture
is a field, it can still reference both fields of reference
pictures and therefore the linesize should allow to address
both fields (for the same reason, data is not offset for
reference pictures).
libavcodec/mpeg12dec.c:1304:41: runtime error: signed integer overflow: 4611686018427387904 * 2 cannot be represented in type 'long'
issue: 69732/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEGVIDEO_fuzzer-5123551179374592
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Possible by using MB_TYPE_CODEC_SPECIFIC for MB_TYPE_ZERO_MV
and due to the MB_TYPE_*_MV flags fitting into an int16_t.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
MB_TYPE_L[01] is based upon H.264 terminology (it stands for
list); yet the mpegvideo based decoders don't have lists
of reference frames, they have at most one forward and one
backward reference. So use terminology based upon this.
This also has a second advantage: MB_TYPE_L[01] is actually
an OR of two flags (which are set independently for H.264,
but aren't for mpegvideo). Switching to different flags
makes the flags fit into an int16_t, which will be useful
in future commits.
The only downside to this is a very small amount of code
in error_resilience.c and mpegutils.c (the only code shared
between the H.264 decoder and mpegvideo).
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>
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>
This is all that is used. This is in preparation for further
commits that will extend ff_mpv_decode_init() in a way
that will make it possible to fail and require cleanup.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There are two types of MPVPictures: Three (cur_pic, last_pic, next_pic)
that are directly part of MpegEncContext and an array of MPVPictures
that are separately allocated and are mostly accessed via pointers
(cur|last|next)_pic_ptr; they are also used to store AVFrames in the
encoder (necessary due to B-frames). As the name implies, each of the
former is directly associated with one of the _ptr pointers:
They actually share the same underlying buffers, but the ones
that are part of the context can have their data pointers offset
and their linesize doubled for field pictures.
Up until now, each of these had their own references; in particular,
there was an underlying av_frame_ref() to sync cur_pic and cur_pic_ptr
etc. This is wasteful.
This commit changes this relationship: cur_pic, last_pic and next_pic
now become MPVWorkPictures; this structure does not have an AVFrame
at all any more, but only the cached values of data and linesize.
It also contains a pointer to the corresponding MPVPicture, establishing
a more natural relationsship between the two.
This already means that creating the context-pictures from the pointers
can no longer fail.
What has not been changed is the fact that the MPVPicture* pointers
are not ownership pointers and that the MPVPictures are part of an
array of MPVPictures that is owned by a single AVCodecContext.
Doing so will be done in a latter commit.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Specifically, add const to the pointed-to-type of pointers
that point to something static or that belong to last_pic
or next_pic (because modifying these might lead to data races).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This avoids an indirection and is in preparation for removing
the AVFrame from MpegEncContext.(cur|last|next)_pic altogether.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
current_picture->cur_pic, last_picture->last_pic, similarly
for new_picture and next_picture.
Also rename the corresponding *_ptr fields.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
MPEG-2 allows to pair an intra field (as first field) together
with a P-field. In this case a conformant bitstream has to satisfy
certain restrictions in order to ensure that only the I field
is used for prediction. See section 7.6.3.5 of the MPEG-2
specifications.
We do not check these restrictions; normally we simply allocate
dummy frames for reference in order to avoid checks lateron.
This happens in ff_mpv_frame_start() and therefore does not happen
for a second field. This is inconsistent. Fix this by allocating
these dummy frames for the second field, too.
This already fixes two bugs:
1. Undefined pointer arithmetic in prefetch_motion() in
mpegvideo_motion.c where it is simply presumed that the reference
frame exists.
2. Several MPEG-2 hardware accelerations rely on last_picture
being allocated for P pictures and next picture for B pictures;
e.g. VDPAU returns VDP_STATUS_INVALID_HANDLE when decoding
an I-P fields pair because the forward_reference was set incorrectly.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
I dont think this can actually overflow but 64bit seems reasonable to use
Fixes: CID1521983 Unintentional integer overflow
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Use context_initialized from the underlying MpegEncContext
instead. Also don't check before ff_mpv_common_end()
in mpeg_decode_end().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The ipu decoder never calls ff_mpv_common_init() or allocates
anything else that would need to be freed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(FF_PTR_ADD has to be kept although MPEG-1/2 only supports
YUV pixel formats because our decoder also supports decoding
to AV_PIX_FMT_GRAY8 depending upon CONFIG_GRAY.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, ff_mpv_frame_start() offsets the data of the current
picture and doubles the linesizes of all pictures if the current
picture is field-based so that data and linesize allow to address
the current field only.
This is done based upon the current picture_structure value.
Only two mpegvideo-based decoders ever set this field: mpeg1/2
and VC-1; but the latter only does it after ff_mpv_frame_start()
(when using hardware-acceleration and in order to signal it to
the DXVA2 hwaccel) in which case no offset is applied in
ff_mpv_frame_start(). So only one decoder actually wants this
offset*; therefore move the code performing it to mpeg12dec.c.
*: VC-1 doubles linesize when using field_mode (not only the picture's
linesize, but also uvlinesize and linesize), yet it does not offset
anything. This is further proof that this should not be performed
generically.
Also move MPEG-1/2 specific setting of the top-field-first flag.
(The change here implies that the AVFrame in current_picture
may have different top-field-first flags than the AVFrame
from current_picture_ptr, but this doesn't matter as only
the latter's are used.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In MPEG-2 user data, there can be different types of Closed Captions
formats embedded (A53, SCTE-20, or DVD). The current behavior of the
CC extraction code in the MPEG-2 decoder is to not be aware of
multiple formats if multiple exist, therefore allowing one format
to overwrite the other during the extraction process since the CC
extraction shares one output buffer for the normalized bytes.
This causes sources that have two CC formats to produce flawed output.
There exist real-world samples which contain both A53 and SCTE-20 captions
in the same MPEG-2 stream, and that manifest this problem. Example of symptom:
THANK YOU (expected) --> THTHANANK K YOYOUU (actual)
The solution is to pick only the first CC substream observed with valid bytes,
and ignore the other types. Additionally, provide an option for users
to manually "force" a type in the event that this matters for a particular
source.
Signed-off-by: Marth64 <marth64@proxyid.net>
