This can happen when user set the avctx->profile field directly
instead of specify profile via option.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Other than save a few bytes, it also has the benefit to show the
AV_OPT_TYPE_CONST value in help, e.g.,
-profile <int> E..V....... Profile (from 0 to INT_MAX) (default 0)
baseline 66 E..V....... Baseline Profile
...
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
H.264 high10/high422/high44 are unlikely supported by devices.
It's there for developers to do the experiment.
H.265 main10 works on my device with AV_PIX_FMT_MEDIACODEC.
OMX_COLOR_FormatYUV420Planar16 doesn't work.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Fixes: 58528/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5834725318328320
Fixes: index 16 out of bounds for type 'int [16]'
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: runtime error: pointer index expression with base 0x000000000000 overflowed to 0xfffffffffffffff8
Fixes: 58440/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5956015530311680
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: avcodec/takdsp.c:44:23: runtime error: signed integer overflow: -2097158 - 2147012608 cannot be represented in type 'int'
Fixes: 58417/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TAK_fuzzer-5268919664640000
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This makes the null pointer checks match mpv_motion_internal()
Fixes: NULL pointer dereference
Fixes: 59671/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG1VIDEO_fuzzer-4993004566609920
Fixes: 59678/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEGVIDEO_fuzzer-4893168991338496
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array read
Fixes: 59673/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG1VIDEO_fuzzer-5194311374077952
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: -38912000 + -2109276160 cannot be represented in type 'int'
Fixes: 59670/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RKA_fuzzer-4987563245699072
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: left shift of 34136248 by 6 places cannot be represented in type 'int'
Fixes: 58429/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RKA_fuzzer-5692211592560640
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The implementation is flawed in that the frame opaque data is not in
fact correctly reordered along with the packets, but is being output in
packet input order, just like the dts are.
This reverts commit 3553809703.
I've been sitting on this for 3 1/2 years now(!), and I finally got
around to fixing the loose ends and convincing myself that it was
correct. It follows the same basic structure as yadif_cuda, including
leaving out the edge handling, to avoid expensive branching.
The issue is that with a threadsafe hwaccel and multiple enabled
frame threads, hwaccel->uninit() is never called.
Previously, the function was guaranteed to never have any threads
with hwaccel contexts, so it never bothered to uninit any.
This reverts commit 9a245bdf5d.
This commit basically broke all samples with fractional framerates,
rather than fixing them.
I at this point do not understand the original issue anymore, and I'm
not sure how this slipped my initial testing.
All my test samples must have happened to have a simple timebase.
The actual dts values pretty much always are just a simple chain of
1,2,3,4,5,... Or maybe slightly bigger steps. Each increase by one means
an advance in time by one unit of the timebase.
So a fractional framerate/timebase is already not an issue.
So with this patch applied, the calculation might end up substracting
huge values (1001 is a common one) from the dts, which would be an
offset of that many frames, not of that many fractions of a second.
This broke at least muxing into mp4, if the sample happened to have a
fractional framerate.
I do not thing the original issue this patch tried to fix existed in the
first place, so it can be reverted without further consequences.
This flag is used to indicate to the hw frames in the gaps,
vaapi constructs it from a bunch of implicit API information
around surface ids. vulkan should just send it explicitly.
Reviewed-by: Lynne <dev@lynne.ee>
Determined experimentally, on various videos and hardware.
On Intel, using less resources in-flight is around 15% faster,
with similar results on Nvidia hardware.
It was introduced for Vulkan, but it is equivalent to
short_term_ref_pic_set_size when !short_term_ref_pic_set_sps_flag,
and when !!short_term_ref_pic_set_sps_flag, Vulkan hardcodes a zero
anyway.
