Without ff_vk_exec_discard_deps which is called by ff_vk_exec_wait,
the reference count of hwframe context cannot reach zero due to
circular reference created by ff_vk_exec_add_dep_frame.
Fix#10873
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
It was always intended that the buffers returned by
RefStruct shall have the same alignment guarantees
as the buffers returned by av_malloc(); said alignment
depends upon the arch and the enabled instruction set
and the code used STRIDE_ALIGN as a proxy for this.
Yet since 7945d30e91
there is a better way to get av_malloc's alignment:
ALIGN_64 in mem_internal.h. So use this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Cloning a packet whose source is going to be unreferenced
immediately afterwards is wasteful.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This decoder uses av_image_copy() to copy decoded images
to buffers obtained via ff_get_buffer(); ergo it can handle
user-provided buffers.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This decoder implements the receive_frame API; such decoders
always have to set the pkt_dts field themselves and the avcodec
test checks for this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes errors when opening streams with no extradata (like those from raw OBU
sources). It also calls get_format() on new Sequence Headers when required.
Signed-off-by: James Almer <jamrial@gmail.com>
Commit 900ce6f8c3 replaced
IntraX8Context.ac_vlc by IntraX8Context.ac_vlc_table,
but forgot to update an av_assert2()*.
cf7ed01938 then
replaced this with a check for j_ac_vlc[mode],
but this makes no sense as j_ac_vlc is of type
const VLCElem [2][2][8][].
Worse yet, mode can be up to three and then
j_ac_vlc[mode] is undefined behaviour. This happened
during the wmv8-x8intra FATE test.
*: Since 84f16bb5e6
config.h was no longer auto-included in avassert.h
and this disabled av_assert1() and av_assert2()
in files where config.h has not been included before
the inclusion of avassert.h.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
So that can show OBU info even it doesn't have decomposed content. And
add OBU content status into the message.
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
Benched using single-threaded full decode on an Ampere Altra.
Bpp Before After Speedup
8 73,3s 65,2s 1.124x
10 114,2s 104,0s 1.098x
12 125,8s 115,7s 1.087x
Signed-off-by: J. Dekker <jdek@itanimul.li>
Fixes the dxv3enc-dxt1 FATE test with UBSan and on big-endian
hardware.
Reviewed-by: James Almer <jamrial@gmail.com>
Tested-by: Sean McGovern <gseanmcg@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
which then end up heap-allocated.
By declaring any variable in a struct, or tree of structs, to be 32 byte
aligned, it allows the compiler to safely assume the entire struct
itself is also 32 byte aligned.
This might make the compiler emit code which straight up crashes or
misbehaves in other ways, and at least in one instances is now
documented to actually do (see ticket 10549 on trac).
The issue there is that an unrelated variable in SingleChannelElement is
declared to have an alignment of 32 bytes. So if the compiler does a copy
in decode_cpe() with avx instructions, but ffmpeg is built with
--disable-avx, this results in a crash, since the memory is only 16 byte
aligned.
Mind you, even if the compiler does not emit avx instructions, the code
is still invalid and could misbehave. It just happens not to. Declaring
any variable in a struct with a 32 byte alignment promises 32 byte
alignment of the whole struct to the compiler.
This patch limits the maximum alignment to the maximum possible simd
alignment according to configure.
While not perfect, it at the very least gets rid of a lot of UB, by
matching up the maximum DECLARE_ALIGNED value with the alignment of heap
allocations done by lavu.