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.
Pass SPS, PPS range extensions to VDPAU layer via
VdpPictureInfoHEVC444. Added VdpPictureInfoHEVC444 struct to
VdpPictureInfo union to populate the range extension params. Mapped
FF_PROFILE_HEVC_REXT to VDP_DECODER_PROFILE_HEVC_MAIN_444.
Fixes: Timeout (11sec -> 5sec)
Fixes: 14473/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JV_fuzzer-5761630857592832
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: Assertion failure
Fixes: 14484/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PGMYUV_fuzzer-5150016408125440
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>
Fixes: signed integer overflow: -2147483648 + -1 cannot be represented in type 'int'
Fixes: 14107/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TRUEMOTION2_fuzzer-5694078680825856
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This follows the spec definition, and removes a field from the relevant
structs.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: James Almer <jamrial@gmail.com>
Also infer the value time_offset_length as 0 when it's not present.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: speed regression with xmap_samsung_gear_2560x1280.pgm
Found-by: Michael Koch
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This reverts nvenc to old behaviour, which in some super rare edge cases
performs better.
The implication of this is that any potential API user who relies on
nvenc cleaning up every frames device resources after it's done using
them will have to change their usage pattern.
That should not be a problem, since pretty much every normal usage
pattern automatically implies that surfaces are reused from a common
pool, since constant re-allocation is also very expensive.
Has a slight speedup.
Can't be carried over to aarch64, since it has no shufps-like instruction.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: value 1.87633e+10 is outside the range of representable values of type 'int'
Fixes: Undefined behavior
Fixes: 14246/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-5758393601490944
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The spec defines the valid range of values to be INT32_MIN + 1 to INT32_MAX, inclusive.
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: Timeout (158sec -> 36sec)
Fixes: 14214/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DSICINVIDEO_fuzzer-5633569034076160
This is untested with valid cin files as none of the files i found cover the changed
codepath
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
There are 2 types of problems when using adaptive deinterlace with cuvid:
1. Sometimes, in the middle of transcoding, cuvid outputs frames with visible horizontal lines (as though weave deinterlace method was chosen);
2. Occasionally, on scene changes, cuvid outputs a wrong frame, which should have been shown several seconds before (as if the frame was assigned some wrong PTS value).
The reason is that sometimes CUVIDPARSERDISPINFO has property progressive_frame equal to 1 with interlaced videos.
In order to fix the problem we should check if the video is interlaced or progressive in the beginning of a video sequence (cuvid_handle_video_sequence).
And then we just use this information instead of the property progressive_frame in CUVIDPARSERDISPINFO (which is unreliable).
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
Zhong Li
Michael Niedermayer
James Almer
ManojGuptaBonda
fumoboy007
Lynne
James Darnley
Michael Stoner
Paul B Mahol
Timo Rothenpieler
Nikolas Bowe
Sergey Svechnikov