MPEG-2 contains several elements that mustn't be zero according to the
specifications: horizontal/vertical_size_value, aspect_ratio_information,
frame_rate_code, the quantiser matrices, the colour_description
elements, picture_coding_type, the f_code[r][s] values and
quantiser_scale_code. It is now checked that the invalid values don't
occur.
The colour_description elements are treated specially in this regard:
Given that there are files in the wild which use illegal values for the
colour_description elements (some of them created by mpeg2_metadata),
they will be corrected to the value meaning "unknown" (namely 2) during
reading. This has been done in such a way that trace_headers will
nevertheless report the original value, together with a message about
the fixup.
Furthermore, the trace_headers output of user_data has been beautified.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: signed integer overflow: -1877966852 + -469491713 cannot be represented in type 'int'
Fixes: 14561/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TRUEMOTION2_fuzzer-5167608359288832
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: Timeout (14sec -> 9sec)
Fixes: 13398/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFV1_fuzzer-5664106709778432
decode_line() becomes 1% faster for fate/vsynth2-ffv1.avi
for another fate sample there is a 0.5% speedup
the effect should be bigger for files with "flat" colored areas
the new faster branch is used in 97-100% of the cases in fate samples
compared to the older more complex (which i tested)
vsynth3-ffv1-v3-bgr0.avi had the lowest percentual useage of about 97%
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In function ff_dct_unquantize_mpeg2_intra_mmi,
addr0 shoudn't be changed before storage operation.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
frame->enc_ctrl.Payload is malloced in get_free_frame, directly memset
the whole structure of enc_ctrl to zero will cause the memory leak for
enc_ctrl.Payload.
frame->enc_ctrl as a structure will be malloc and init to zero by calling
frame = av_mallocz(sizeof(*frame)), so the memset is redundant and can
be removed.
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Signed-off-by: Zhong Li <zhong.li@intel.com>
As suggested by Ronald, don't map auto threads to frame threads only, and
instead distribute them between frame and tile more efficiently.
Add a new framethreads override option, similar to the tilethreads one.
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: "null pointer dereference" (actually misaligned access but the tools seem not to support this)
Fixes: 14551/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_V210_fuzzer-5088609952071680
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Hardware-accelerated encoding may not support 10-bit encoding. Use
'-require_sw 1' in this case.
Fixes: #7581
Signed-off-by: Rick Kern <kernrj@gmail.com>
Fixes: signed integer overflow: -2147483648 + -1 cannot be represented in type 'int'
Fixes: 14444/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5675880333967360
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
perfer avctx->framerate first than use avctx->time_base when setting
the frame rate to encoder. 1/time_base is not the average frame rate
if the frame rate is not constant, so use avctx->framerate if the
value is not zero.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
perfer avctx->framerate first than use avctx->time_base when setting
the frame rate to encoder. 1/time_base is not the average frame rate
if the frame rate is not constant. In this case, we need to setting
avctx->framerate and avctx->time_base both, but avctx->framerate not
equal to 1/(avctx->time_base).
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Cuvid supports clips with a limit on maximum number of macroblocks.
This check was missing after cuvidGetDecoderCaps API call allowing
unsupported clips to proceed.
Added the missing check, same as the one in hwaccel nvdec implementation.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
Currently profile mapping is hard-coded, and not flexible to do extactly
map (E.g: libmfx treats H264 constrained baseline to be baseline profile).
vaapi profile mapping funtion provides a better soultion than current
qsv mapping.
Signed-off-by: Zhong Li <zhong.li@intel.com>
It is helpful to know why some clips decoding failed.
Ticket#7330 is a good example, with this patch it is easily to
know bitstream codec level is out of support range.
Signed-off-by: Zhong Li <zhong.li@intel.com>
Reference: Table 8: Interpretation of valid BITPIX value from FITS standard 4.0
Fixes: runtime error: division by zero
Fixes: 14581/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FITS_fuzzer-5652382425284608
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The latest generation video decoder on the Turing chips supports
decoding HEVC 4:4:4. This change adds AV_PIX_FMT_VDPAU as a valid format
for HEVC 4:4:4 8 bit.
