The 2 which has been changed to an 8 in the array length expression is
the maximum value of sps_bitdepth_minus8. This was missed when updating
to VVCv2, which increased this maximum from 2 to 8.
Signed-off-by: Frank Plowman <post@frankplowman.com>
The size variable here is taken as gospel for the bounds of the input
buffer in later logic. Clamp it to ensure that the returned region
does not extend past that allocated in the underlying GetBitContext,
even in the case entry point offsets are signalled in the bitstream.
Also assert this for good measure.
Signed-off-by: Frank Plowman <post@frankplowman.com>
num_units_in_tick and time_scale are both 32-bit unsigned integers.
Storing them as ints was causing overflows.
Signed-off-by: Frank Plowman <post@frankplowman.com>
Invalid input files may contain film grain metadata which survives
ff_h274_film_grain_params_supported() but does not pass
av_film_grain_params_select(), leading to a SIGSEGV on hevc_frame_end().
Fix this by duplicating the av_film_grain_params_select() check at frame
init time.
An alternative solution here would be to defer the incompatibility check
to hevc_frame_end(), but this has the downside of allocating a film
grain buffer even when we already know we can't apply film grain.
Fixes: https://trac.ffmpeg.org/ticket/10951
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>
H.261 does not have keyframes (or indeed frame types) at all,
so this warning is not warranted.
Also remove an always-true check while at it.
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>
current_picture is not changed after frame_start() at all
and it therefore does not need to be updated (i.e. copied to the
slice thread contexts) a second time.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These pointers already point to the same buffers, so using
a union is possible and avoids the overhead of syncing the
pointers (and saves some memory).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
A decoder's private data has already been zeroed (apart from options)
before init is called.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Key line from the spec is:
"All SPS NAL units with a particular value of sps_seq_parameter_set_id
in a CVS shall have the same content."
Prior to this patch, the VVC decoder's behaviour on encountering a
duplicated SPS ID (within the entire bitstream, not restricted to
a CVS) was simply to replace the entry in the SPS lookup table with the
new data. Illegal bitstreams with multiple SPSs in the same CVS sharing
an ID but differing elsewhere could cause all manner of issues.
The patch tracks which SPS IDs have been used in the given CVS using the
new sps_id_used field of VVCParamSets. If it encounters an SPS with an
ID already in use and whose content differs from the previous SPS, it
throws an AVERROR_INVALIDDATA.
Signed-off-by: Frank Plowman <post@frankplowman.com>
ff_ass_subtitle_header_* still used explicit CRLF linebreaks
eventhough they will get normalised to LF later since commit
7bf1b9b357. Just directly use LF.
Unlike what the old comment suggested, standard ASS has no character
escape mechanism, but a closing curly bracket doesn't even need one.
For manual authored sub files using a full-width variant of an
appropriate font and with scaling and spacing modifiers is a common
workaround.
This is not an option here, but we can still make things much less bad.
Now the desired opening bracket still shows up in libass, and
standard renders will merely display a backslash in its place
instead of stripping the following text like before.
Backslashes cannot be escaped by a backslash in any ASS renderer,
but unless followed by specific characters it is just printed out.
Insert a word-joiner character after a backslash to break up
active sequences without changing the visual output.
v2.0.0 is already four years old and even newer versions are available on
stable distro releases.
With this we stop setting codec capabilities during static data initialization.
Signed-off-by: James Almer <jamrial@gmail.com>
Frank Plowman
Niklas Haas
James Almer
Andreas Rheinhardt
Geoff Hill
Antoine SOULIER
Oneric