call_kernel() obtains the command buffer and compute encoder from
property getters (mtlQueue.commandBuffer, buffer.computeCommandEncoder),
which return autoreleased references under the non-ARC build, and then
releases them via ff_objc_release(). That is an over-release: when the
enclosing autorelease pool is drained, the objects are released a second
time and the process crashes with EXC_BAD_ACCESS in objc_release.
On current macOS this is reproducible with the ffmpeg CLI itself. The
filter thread's thread-local autorelease pool is popped during pthread
TSD cleanup at thread exit, so any run that used yadif_videotoolbox
crashes when the filter thread terminates:
ffmpeg -init_hw_device videotoolbox=vt -filter_hw_device vt \
-f lavfi -i testsrc2=size=640x480:rate=30 \
-vf setfield=tff,format=nv12,hwupload,yadif_videotoolbox,\
hwdownload,format=nv12 -frames:v 20 -f null -
Thread 11 Crashed:: vf#0:0
0 libobjc.A.dylib objc_release + 16
1 libobjc.A.dylib AutoreleasePoolPage::releaseUntil(objc_object**) + 204
2 libobjc.A.dylib objc_autoreleasePoolPop + 244
3 libobjc.A.dylib objc_tls_direct_base<...>::dtor_(void*) + 156
4 libsystem_pthread.dylib _pthread_tsd_cleanup + 620
5 libsystem_pthread.dylib _pthread_exit + 84
Host applications hit the same crash earlier, for example when a
dispatch queue drains its last-resort pool after a work item that ran
the filter.
Wrap the kernel invocation in @autoreleasepool and drop the manual
releases, making the pool pop the single balanced release and draining
the Metal transients once per frame. The ff_objc_release() calls on the
s->mtl* members in do_uninit() stay: those hold owned references
obtained from new* methods.
(cherry picked from commit 7f2e5cdd7c)
Limit the 8-bit column filter to the pixels remaining in the current slice. Pass slice_end - y at all three call sites so both the 8-bit and high-bit-depth column filters receive the correct remaining width. This handles partial 16-pixel blocks at frame and thread-slice boundaries. The non-column callbacks do not use this argument.
Fixes: #YWH-PGM40646-36
(cherry picked from commit 8b9e02cc17)
The decoder can't know where a seek landed, so the "delay_samples" way to
discard the decoder delay in the first frame is not truly viable, so it needs
to be removed.
Add a call to aacDecoder_DecodeFrame() with the AACDEC_CLRHIST flag set, as the
call to aacDecoder_SetParam() with the AAC_TPDEC_CLEAR_BUFFER setting was
seemingly not enough to truly flush all the fdkaac internal buffers.
Should fix issue #24527.
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit b894a6f7c1)
Shift timestamps when available, and take into account the caller requested
samples to be discarded alongside the decoder delay.
Should fix issue #24526.
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit c8595be8e6)
The code reads a mask afer this check, meaning it expects NATIVE order, not
others.
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit 7755d264bd)
Don't depend on the generic code setting this.
This is in preparation for a following change.
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit 281b7fc02e)
The output stream no longer has extension sub-streams, so the
declared input profile, if it was set, is no longer valid.
Fixes issue #24388.
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit 7dc71230a9)
To determine whether the colocated picture is field coded, the temporal
and spatial direct setup peek at
sl->ref_list[1][0].parent->mb_type[mb_xy] before mb_xy has been remapped
to the colocated field's parity. That row belongs to the current field's
parity, while await_reference_mb_row() above waited on the parity of the
referenced field, so whenever the two differ the load is unsynchronised
and with frame threading can observe macroblocks of a field that is
still being decoded.
Every macroblock of a field picture has MB_TYPE_INTERLACED set, so
checking field_picture first gives the same result in all correctly
synchronized cases without touching the mb_type array.
This also fixes few TSAN reported warnings.
Fixes: https://trac.ffmpeg.org/ticket/10891
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
(cherry picked from commit c3a8a223b29260dc170d41c62f9b3b33f6b97b2d)
h264_frame_start() clears h->er.cur_pic, and decode_nal_units() only sets
it again for pictures that are not field coded, right before running error
concealment. A second field goes through neither, so h->er.cur_pic keeps
pointing at whatever frame coded picture the context decoded earlier.
With frame threading the two fields of a pair are decoded by different
contexts, so whether this triggers depends on what the context that picks
up the second field decoded before, which is why the number of bogus
warnings varies between runs.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
(cherry picked from commit f1d318e5eb2eb487d2be4b4b721b93ae76fd5ba7)
When a frame coded picture uses a complementary field pair as its
colocated picture, ff_h264_direct_ref_list_init() selects the field whose
POC is closest to the current one and stores it in col_parity. The direct
mode setup then remaps mb_xy to that parity and reads the colocated
mb_type, motion_val and ref_index from it.
await_reference_mb_row() waits on the field given by "ref_field_picture &&
ref_field", which is 1 for any such reference, since the pair is
referenced as a frame and ref->reference is 3. Only the bottom field is
therefore awaited, while the data is just as likely to be read from the
top one. With frame threading the two fields are decoded by different
threads, so the colocated data can be read while the field it belongs to
is still being decoded, yielding stale motion vectors and a corrupt
frame. await_references() already handles the same case correctly for
motion compensation.
Fixes sporadic failures of fate-h264-conformance-cabac_mot_picaff0_full,
where display frame 14.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
(cherry picked from commit 274cb6731bd204e9537a7e588d4a3436fdf51b93)
The documentation for get_buffer2() states:
"This callback must use the frame values, not the codec context values, to
calculate the required buffer size."
Fixes wrong output on hbd LCEVC enhanced samples where the base stream is
8bit.
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit e1c1b6c558)
Here is a proposed patch for portability of doc/t2h.pm for GNU Texinfo
7.1 and 7.1.90 (7.2 pretest). I tested against 7.1 and 7.1.90 (7.2
pretest). There is a difference in the headings compared to the website
version, maybe related to FA_ICONS not being set the same, but the
result seems correct.
I also renamed $element to $output_unit in ffmpeg_heading_command as in
new equivalent makeinfo/texi2any code the $element variable is the
$command variable in ffmpeg_heading_command, which is very confusing. I
left as is the $command variable to have a patch easier to read, but it
could make sense to rename $command as $element later on.
The patch could also have effects with Texinfo 7.0, since some of the
changes are for that version, but that probably never show up because it
is for situations that may not exist in ffmpeg manuals (for example
@node without sectioning command), or because the code is robust to some
missing information (case of $heading_level in ffmpeg_heading_command
that was not set, as far as I can tell).
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit 4d9cdf82ee)
This is a behavior preserving change for all non-overflowing cases.
Slice-based filters computed per-slice boundaries as (dim * jobnr) / nb_jobs
in int, which overflows for large dimensions with many slice threads,
yielding wrong slice bounds and out-of-array accesses. ff_slice_pos()
performs the multiplication in 64bit.
Backported to 5.1: applied the ff_slice_pos() conversion to the filters
present in 5.1 (filters added after the 5.1 branch are skipped), and added
the required filters.h includes. ff_slice_pos() itself is already present
in 5.1. Channel-count based slices (bounded, cannot overflow) are left as
in 6.1.
(cherry picked from commit f7368f97b9)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Some awk implementations like mawk (used on Ubuntu) do not support
these.
(cherry picked from commit 4858a8ee2f)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The symbol prefix check would incorrectly detect a bogus prefix in
circumstances where sanitizers instrument the build, like when
configuring with the clang-asan toolchain where it would detect the
prefix as __odr_asan_gen_, which is obviously wrong.
To fix this, adjust the prefix detection to only detect a
one-character prefix, which is the only case that matters
anywhere right now.
(cherry picked from commit 910bf33879)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Common symbols are not part of ISO-C and therefore not used
by FFmpeg at all. Yet linker warnings to ensure it stays
that way are nevertheless wrong, because the existence of
common symbols does not imply that there is a bug in our code.
More precisely, Clang's ASAN implementation uses a common symbol
___asan_globals_registered when used on Elf targets with
the -fsanitize-address-globals-dead-stripping option;
said option is the default since Clang 17 [1].
This leads to 1883 warnings about ___asan_globals_registered
when linking here.
(Even without that option there were warnings like
_ZN14__interception10real_vforkE being overridden.)
Said warning is also unnecessary: The proper way to ensure
that our code is free of common symbols is to let the compiler
enforce this. But this is already the default since GCC 10
and Clang 11, so there is no risk of introducing our own
common symbols.
[1]: https://reviews.llvm.org/D152604
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 25e0e087c4)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Backported to 5.1's MPV_motion_lowres() in mpegvideo.c.
(cherry picked from commit adfe003f51... adapted to 5.1 mpegvideo.c)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array read in the chroma plane
Backported to 5.1's mpeg_motion_lowres() in mpegvideo.c.
(cherry picked from commit e8a2d5fca3... adapted to 5.1 mpegvideo.c)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Backported to 5.1's mpeg_motion_lowres() in mpegvideo.c.
(cherry picked from commit d7d3f1af2a... adapted to 5.1 mpegvideo.c)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The DVD subtitle parser handles two types of packets: "normal"
packets with a 16-bit length, and HD-DVD packets that set the
16-bit length to 0 and encode a 32-bit length in the next four
bytes. This implies that HD-DVD packets are at least six bytes
long, but the code didn't actually verify this.
The faulty length check results in an out of bounds read for
zero-length "normal" packets that occur in the input, which are
only 2 bytes long, but get misinterpreted as an HD-DVD packet.
When this happens the parser reads packet_len from beyond the
end of the input buffer. The subtitle stream is not correctly
decoded after this point due to the garbage packet_len.
Fixing this is pretty simple: fix the length check so packets
less than 6 bytes long will not be mistakenly parsed as HD-DVD
packets.
Signed-off-by: Aidan MacDonald <aidanmacdonald.0x0@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
(cherry picked from commit a4405cc0cc)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
For frames with height <= 4, filter_intra reads cur[+-3*refs] out of the
plane. Route those rows to filter_edge instead. (The fate ref tests this
commit touches upstream do not exist in 5.1.)
(cherry picked from commit fdfe4d2cfb... adapted to 5.1 vf_bwdif.c)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Backported to 5.1's ff_color_frame() in utils.c: for chroma width 1,
bytes-2 underflowed to a huge size in av_memcpy_backptr() -> heap
out-of-bounds write. Guard the writes and use 2*(bytes-1).
(cherry picked from commit b47f49586c... adapted to 5.1 ff_color_frame)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Reject block_align larger than the sub_packet_h * frame_size buffer to
avoid a heap out-of-bounds write when deinterleaving RealAudio subpackets.
(cherry picked from commit 20fc83fa5b... adapted to 5.1 structure)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
ham_buf was read uninitialized in some code paths.
(cherry picked from commit 7d62dfda4c... adapted to 5.1 context)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Comply with "For purposes other than determining the amount of data in the decoding units
of the bitstream, decoders shall ignore all data that follow the value 63 for nuh_layer_id in a NAL unit"
Rec. ITU-T H.265 v8 (08/2021) Page 67
Fixes: index 63 out of bounds for type 'const int8_t[63]' (aka 'const signed char[63]')
Fixes: clusterfuzz-testcase-fuzzer_loadfile-5109286752026624
Reported-by: Kacper Michajlow <kasper93@gmail.com>
Found-by: ossfuzz
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 360e7cafd0)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit d2077aeb8e)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Adapted for 5.1: the non-handler branch used av_buffer_alloc() which does
not zero the payload, so SEI payload fields that are only conditionally
written were read uninitialized. Use av_buffer_allocz() instead.
(cherry picked from commit 67e4f737ed... adapted)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This function overreads the input plane for odd dimensions, because the
chroma plane is always rounded up, which means (xy << subsample) + 1 exceeds
the actual alpha plane size.
To verify:
valgrind ffmpeg -pix_fmt yuva420p -f lavfi -i color -vf \
"scale=1x1,format=yuva420p,scale=alphablend=uniform_color,format=yuv420p \
-vframes 1 -f null -
Fixes: https://trac.ffmpeg.org/ticket/11692
(cherry picked from commit b7946098b1)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 2a1d9c080f)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
It may be invalidated by the time it is used.
Fixes use after free when accessing current segment.
Fixes: #10825
Signed-off-by: J. Dekker <jdek@itanimul.li>
(cherry picked from commit b2b23f353a)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 6c395546f0)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array access
Fixes: crash-0d640731c7da52415670eb47a2af701cbe2e1a3b
Fixes: crash-e745864ead6ea418959c8df56de2765571201dae
Found-by: Catena cyber <contact@catenacyber.fr>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 605fc72f19)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 852b178240)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
