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>
ff_vvc_frame_rpl uses the flags to detect whether a frame is in use.
Therefore, in the case of a CVSS AU (RASL/GDR with
NoOutputBeforeRecoveryFlag) with ph_non_ref_pic_flag = 1, the frame
would be freed before it is used. Fix this by always marking the
current frame with VVC_FRAME_FLAG_SHORT_REF, as is done by the HEVC
decoder.
Signed-off-by: Frank Plowman <post@frankplowman.com>
Perform av_clip_int16(val) _after_ copying the value to last_dc.
This change ensures that clipping is applied only within the context of
the current block, preventing the propagation of clipped values to
subsequent DC components.
Related commits: c28f648b19 and dffae122d0
Related ticket: 4683
Fixes use of uninitialized value in memcmp below, reported by MSAN.
Found by OSS-Fuzz.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Before the patch, disable threads support at configure/build time
was the only method to force zero thread in executor. However,
it's common practice for libavcodec to run on caller's thread when
user specify thread number to one. And for WASM environment, whether
threads are supported needs to be detected at runtime. So executor
should support zero thread at runtime.
A single thread executor can be useful, e.g., to handle network
protocol. So we can't take thread_count one as zero thread, which
disabled a valid usercase.
Other libraries take -threads 0 to mean auto. Executor as a low
level utils doesn't do cpu detect. So take thread_count zero as
zero thread, literally.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
