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.
After the commit 9f61abc811, we can use AVFormatContext.strict_std_compliance
instead of HLSContext.strict_std_compliance to avoid the code redundancy.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
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>
The function in case of n=0 would read more bytes than 0.
The end pointer could be beyond the allocated space, which
is undefined.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: use of uninitialized variables
Fixes: blank.aa
Found-by: Chamal De Silva <chamal.desilva@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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>
The spec in https://xiph.org/vorbis/doc/v-comment.html states that
the metadata keys are case-insensitive, so don't change the case
and update the fate test case.
Fix#7784
Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
