This is needed by later hwaccel code to tell which encoding process was
used for a particular frame, because hardware decoders may only support a
subset of possible methods.
This makes it easier for users of the CBS API to get alloc/free right -
all subelements use the buffer API so that it's clear how to free them.
It also allows eliding some redundant copies: the packet -> fragment copy
disappears after this change if the input packet is refcounted, and more
codec-specific cases are now possible (but not included in this patch).
This is harmless and should not be a warning - unknown units are passed
through to the write functions unchanged, and no other code will interact
with them.
This removes the arbitrary limit on the allowed number of slices and
parameter buffers.
From ffmpeg commit e4a6eb70f4.
Signed-off-by: Mark Thompson <sw@jkqxz.net>
Fixes: signed integer overflow: -2072 + -2147483646 cannot be represented in type 'int'
Fixes: 6097/clusterfuzz-testcase-minimized-5034145253163008
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: 6037/clusterfuzz-testcase-minimized-5030249784934400
Fixes: signed integer overflow: 256 * 16992036 cannot be represented in type 'int'
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: -1625276744 + -1041893960 cannot be represented in type 'int'
Fixes: 5948/clusterfuzz-testcase-minimized-5791479856365568
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: signed integer overflow: 361 * -6295541 cannot be represented in type 'int'
Fixes: 5911/clusterfuzz-testcase-minimized-6450382197751808
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
Fixes: 5796/clusterfuzz-testcase-minimized-5206729085157376
Does someone have a valid sample that triggers this path ?
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This refactor splits up the main mediacodec decode loop into two
send/receive helpers, which are then used to rewrite the receive_frame
callback and take full advantage of the new decoding api. Since we
can now request packets on demand with ff_decode_get_packet(), the
fifo buffer is no longer necessary and has been removed.
This change was motivated by behavior observed on certain Android TV
devices, featuring hardware mpeg2/h264 decoders which also deinterlace
content (to produce multiple frames per field). Previously, this code
caused buffering issues because queueInputBuffer() was always invoked
before each dequeueOutputBuffer(), even though twice as many output
buffers were being generated.
With this patch, the decoder will always attempt to drain new frames
first before sending more data into the underlying codec.
Signed-off-by: Matthieu Bouron <matthieu.bouron@gmail.com>
Fixes: 5894/clusterfuzz-testcase-minimized-5315325420634112
Fixes: runtime error: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
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: 3 + 2147483647 cannot be represented in type 'int'
Fixes: 5888/clusterfuzz-testcase-minimized-5634701067812864
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: integer overflows
Reported-by: "Xiaohan Wang (王消寒)" <xhwang@chromium.org>
Based on limits in "8.5 Transform coefficient decoding process and picture
construction process prior to deblocking filter process"
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
And remove the function altogether while at it. It's a duplicate of
another.
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
This effectively copies the side data elements from src instead of
potentially merging them with those already existing in dst.
This by extension also removes the only dependency on existing values
in the dst packet.
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
When ff_h264_decode_mb_cavlc() failed due to wrong sl->qscale values,
e.g. dquant out of range, set the qscale to be a valid value before
returning -1 and exiting the function. The qscale value can be used
later e.g. in loop filter.
BUG=806122
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In a recent commit the default was changed from 0 (component) to 5
(unspecified), however some standards require using 0. With this option, the
user will be able to do so.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Marton Balint <cus@passwd.hu>
MFX_LOOKAHEAD_DS_UNKNOWN means auto.
-1 is not a valid value.
Signed-off-by: Ruiling Song <ruiling.song@intel.com>
Signed-off-by: Maxym Dmytrychenko <maxim.d33@gmail.com>
AVBR is supported from API 1.3 but only available for Windows
Signed-off-by: Zhong Li <zhong.li@intel.com>
Signed-off-by: Maxym Dmytrychenko <maxim.d33@gmail.com>
This number is definitely required when frame threading is enabled, so
add it here rather than forcing all users to handle it themselves.
DXVA2 contained this addition in specific code as well (therefore being
added twice in the internal case) - just remove it from there.
AVCodecContext.extra_hw_frames is added to the size of hardware frame
pools created by libavcodec for APIs which require fixed-size pools.
This allows the user to keep references to a greater number of frames
after decode, which may be necessary for some use-cases.
It is also added to the initial_pool_size value returned by
avcodec_get_hw_frames_parameters() if a fixed-size pool is required.
In 16x8 motion compensation, for lower 16x8 region, the input to mpeg_motion() for motion_y was "motion_y + 16", which causes wrong rounding. For 4:2:0, chroma scaling for y is dividing by two and rounding toward zero. When motion_y < 0 and motion_y + 16 > 0, the rounding direction of "motion_y" and "motion_y + 16" is different and rounding "motion_y + 16" would be incorrect.
We should input "motion_y" as is to round correctly. I add "is_16x8" flag to do that.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Mark Thompson
Michael Niedermayer
Jun Zhao
Aman Gupta
Jérôme Martinez
James Almer
Yusuke Nakamura
Xiaohan Wang
Marton Balint
Rostislav Pehlivanov
Diego Biurrun
Michael Niedermayer
Ruiling Song
Zhong Li
Muhammad Faiz
Nekopanda