According to the H.264 standard, Annex D, Table D-1, field_pic_flag shall be 0 when sei_pic_struct signals progressive. In the case when this restriction is not fullfilled, its safer to assume the field is actually interlaced.
Not doing so can cause a renderer to assume the frame is progressive and not deinterlace it, even if required.
Alot of files have their DefaultDuration set to an calculated
value which is not directly tied to the FPS, and because Matroska
actually doesn't specify the DefaultDuration to be tied to the FPS,
this is perfectly legal.
So, before assuming the DefaultDuration is the FPS, check if the value
actually makes sense. The most basic check here is that the FPS is
below 125fps, because any more really doesn't make sense.
If the FPS from the header is not set, avformat will probe the FPS
based on the files timestamps, which will give a much better result.
Judging by the coefficients, the last round of add/sub can overflow
to 17 bits with a very small probability just as with the 8-point
transform. This is not observed under FATE, but better safe than sorry.
The last set of additions/subtractions can break the 16-bit limit, and
require 17 bits of precision. This uses widening adds accordingly to fix
the MSS2 FATE tests.
The problem potentially also affects inv_trans_4 with a very low
probability, but this is not reproducible under FATE.
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>
If view is defined in the child stri box, then the type must be set to
unspecified, as these boxes don't carry packing information.
Also, don't attach a useless Stereo 3D side data if the stream is monoscopic.
Signed-off-by: James Almer <jamrial@gmail.com>
