The issue is that while decode_slice is guaranteed to never get
called without start_frame, end_frame is not. Moreover, it is
not guaranteed it won't be called twice.
On a badly-broken sample, this is what happens, which leads to
a segfault, as vp->slices_buf doesn't exist, as it has been handed
off for decoding already and isn't owned by the frame.
Return an error as it's indicative that it's a corrupt stream rather
than just missing any slices.
Prevents a segfault.
Should fix integer overflows, and improve encoding results.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: signed integer overflow: 256 * 668003712 cannot be represented in type 'int'
Fixes: 59819/clusterfuzz-testcase-minimized-ffmpeg_dem_MATROSKA_fuzzer-4674636538052608
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Parse through all NALUs in a packet, pull new ones when a complete AU could not
be assembled, or keep them around if an AU was assembled while data remained in
them.
Signed-off-by: James Almer <jamrial@gmail.com>
Default GOP size is now set by preset and tuning info. This GOP size is only overwriten if -g value is provided.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
As per the spec:
VUID-VkVideoDecodeH264PictureInfoKHR-sliceCount-arraylength
sliceCount must be greater than 0
VUID-VkVideoDecodeH265PictureInfoKHR-sliceSegmentCount-arraylength
sliceSegmentCount must be greater than 0
This particularly happens with seeking in field-coded H264.
This commit scraps a bool to signal to recreate the session parameters,
but instead destroys them, forcing them to be recreated.
As this can happen between start_frame and end_frame, do this
at both places.
Move the slice offsets buffer to the thread decode context.
It isn't part of the resources for frame decoding, the driver
has to process and finish with it at submission time.
That way, it doesn't need to be alloc'd + freed on every frame.
This requires using the new AVHWFramesContext.opaque field, as
otherwise, the profile attached to the decoder will be freed
before the frames context, rendering the frames context useless.
Fixes: 1.70141e+38 is outside the range of representable values of type 'int'
Fixes: 59883/clusterfuzz-testcase-minimized-ffmpeg_BSF_EVC_FRAME_MERGE_fuzzer-5557887217565696
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
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>
