Fixes: CID1591932 Ignoring number of bytes read
Sponsored-by: Sovereign Tech Fund
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 1107820800 + 1107820800 cannot be represented in type 'int'
Fixes: left shift of 1091059712 by 6 places cannot be represented in type 'int'
Fixes: 69910/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VVC_fuzzer-5162839971528704
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Nuo Mi <nuomi2021@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This patch is to make FFHWBaseEncodeContext a standalone component
and avoid getting FFHWBaseEncodeContext from avctx->priv_data.
This patch also removes some unnecessary AVCodecContext arguments.
For receive_packet call, a small wrapper is introduced.
Signed-off-by: Tong Wu <tong1.wu@intel.com>
This implementation is based on D3D12 Video Encoding Spec:
https://microsoft.github.io/DirectX-Specs/d3d/D3D12VideoEncoding.html
Sample command line for transcoding:
ffmpeg.exe -hwaccel d3d12va -hwaccel_output_format d3d12 -i input.mp4
-c:v hevc_d3d12va output.mp4
Signed-off-by: Tong Wu <tong1.wu@intel.com>
Move receive_packet function to base. This requires adding *alloc,
*issue, *output, *free as hardware callbacks. HWBaseEncodePicture is
introduced as the base layer structure. The related parameters in
VAAPIEncodeContext are also extracted to HWBaseEncodeContext. Then DPB
management logic can be fully extracted to base layer as-is.
Signed-off-by: Tong Wu <tong1.wu@intel.com>
When allocating the VAAPIEncodePicture, pic->input_surface can be
initialized right in the place. This movement simplifies the send_frame
logic and is the preparation for moving vaapi_encode_send_frame to the base layer.
Signed-off-by: Tong Wu <tong1.wu@intel.com>
Since VAAPI and future D3D12VA implementation may share some common parameters,
a base layer encode context is introduced as vaapi context's base.
Signed-off-by: Tong Wu <tong1.wu@intel.com>
Compare actual PPS objects rather than just PPS ID, as the former might
change while the latter stays the same.
Reported-by: Michael Niedermayer <michael@niedermayer.cc>
The only other caller of set_sps() --- hevc_update_thread_context() ---
does not need to call export_stream_params(), since it only updates
AVCodecContext fields that have already been updated by generic code.
It is merely copied to AVCodecContext.pix_fmt, which serves no useful
purpose. set_sps() is called from two places:
* when a new SPS becomes active - then the pixel format is
overridden immediately after the set_sps() call by the result from
ff_get_format();
* when a new SPS is propagated across frame threads - then the
AVCodecContext value is already set to the same value by the generic
code.
Add check for av_packet_new_side_data() to avoid null pointer
dereference if allocation fails.
Fixes: bdc1220eeb ("h263enc: Add an option for outputting info about MBs as side data")
Signed-off-by: Jiasheng Jiang <jiashengjiangcool@outlook.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Chapters and duration are calculated together in dvdvideo demuxer.
Previous chapter calculation logic treated extraction of 1 chapter
using chapter_start and chapter_end switches incorrectly, returning
the duration of the entire title instead of just the segment.
Fix the logic so that it calculates and returns the duration of the
chapter segment instead. Additionally, validate that chapter_end
exceeds chapter_start (except in the special case of 0).
Signed-off-by: Marth64 <marth64@proxyid.net>
A DVDNAV_WAIT event by itself should not warrant an
EOF when navigating the program stream. Some discs
have WAIT events in the middle of a title, causing
playback to end prematurely prior to this fix.
Signed-off-by: Marth64 <marth64@proxyid.net>
In intra-only mode, frameIntervalP is 0, which means the frame
data array is smaller than the number of surfaces.
Together with using the wrong size on deallocation of the
frame_data_array, this lead to a crash.
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
Judging by the coefficients, the last round of add/sub can overflow
to 17 bits with a very small probability just as with the 8-point
transform. This is not observed under FATE, but better safe than sorry.
The last set of additions/subtractions can break the 16-bit limit, and
require 17 bits of precision. This uses widening adds accordingly to fix
the MSS2 FATE tests.
The problem potentially also affects inv_trans_4 with a very low
probability, but this is not reproducible under FATE.
These values are not read anywhere. Furthermore, since commit
fe6037fd04 the linesize values
of the MPVWorkPictures were wrong for subsequent fields
in a chain of B-pictures (as they are always doubled and no longer
based upon the frame-linesizes) which can eventually lead to overflow.
Finally, it makes no real sense to ever double the linesize
of the reference pictures at all: Even when the current picture
is a field, it can still reference both fields of reference
pictures and therefore the linesize should allow to address
both fields (for the same reason, data is not offset for
reference pictures).
libavcodec/mpeg12dec.c:1304:41: runtime error: signed integer overflow: 4611686018427387904 * 2 cannot be represented in type 'long'
issue: 69732/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEGVIDEO_fuzzer-5123551179374592
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
If view is defined in the child stri box, then the type must be set to
unspecified, as these boxes don't carry packing information.
Also, don't attach a useless Stereo 3D side data if the stream is monoscopic.
Signed-off-by: James Almer <jamrial@gmail.com>
Given that a video stream/frame may have only one view or both views coded with
the packing information being unavailable, this commit adds a new type value
AV_STEREO3D_UNSPEC for this purpose.
The most common case for this is container level signaling of Stereo3D video
where the specifics are defined at the bitstream level.
Signed-off-by: James Almer <jamrial@gmail.com>
