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)
Backport of bedfb6eca4 to release/6.0.
AAC Main can select three TNS filters, but the old direction calculation only allocates two energy measurements and reads beyond that array for the third filter. Measure all three regions and compare each filter with the following region.
Fixes: CVE-2025-1594
Fixes: https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/22696
Found-by: 0x20z
Signed-off-by: lizhixuan.HUST <2069360659@qq.com>
Assisted-by: Fairy
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)
celt_header() reads a uint32 `extra_headers` field from the CELT identification
header and stores `1 + extra_headers` into the signed int extra_headers_left.
With extra_headers = 0x7FFFFFFE this becomes INT_MAX and the OGG parser
consumes every subsequent page as a CELT "extra header" without ever reaching
audio data, hanging on any streaming input. A value of 0xFFFFFFFE wraps the
signed addition negative, with the same family of consequences.
Reject any extra_headers count above a small fixed cap (16, well above any
real CELT-over-Ogg stream).
Verified with the audit PoC (a crafted file plus an infinite-page FIFO):
without the patch, ffmpeg consumes pages forever; with the patch it logs
"Too many CELT extra headers (...)" and exits in ~70 ms with
AVERROR_INVALIDDATA.
Reported by Franciszek Kalinowski (isec.pl / striga.ai) and Bartosz Smigielski.
(cherry picked from commit 87439ed619)
You may look and think `AVFMT_FLAG_CUSTOM_IO` check is enough, but this
is not what it seems. This flag means that user provided custom
AVIOContext, before creating AVFormatContext and it should not be
closed. However nested sub-demuxers may still open an temporary io, and
those have to be closed and use correct io_close2 function.
You can see 0dcac9c3f0 and
ef01061225 where this flag is cleared for
nested opens to avoid leaking those.
lavf micro version bumped so API users can know if it is safe to use
custom io.
(cherry picked from commit dc74fe70b2)
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
io_open_default() will call internal impl if needed, don't call it
directly.
(cherry picked from commit 06ef9a74ea)
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
io_open_default() will call internal impl if needed, don't call it
directly.
(cherry picked from commit 4cf687b3b1)
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
io_open_default() will call internal impl if needed, don't call it
directly.
(cherry picked from commit fbc4003642)
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Fixes issue #22333.
Note: These functions have been removed in commit
61e851381f, so the issue
only affects releases 7.0 and older.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 5e6c584b98)
Not entirely sure if it should instead use some entirely different
approach here, given that images exceeding 2GB don't seem that crazy
to me, but so far processing such images results in a heap overflow,
since the size addition overflows and a much too small packet is
allocated and its size never checked again when writing into it.
Fixes #YWH-PGM40646-32
(cherry picked from commit f6a95c7eb7)
The mismatch between neon and C functions can be reproduced
using the following bitstream and command line on aarch64 devices.
wget https://streams.videolan.org/ffmpeg/incoming/replay_intra_pred_16x16.h264
./ffmpeg -cpuflags 0 -threads 1 -i replay_intra_pred_16x16.h264 -f framemd5 -y md5_ref
./ffmpeg -threads 1 -i replay_intra_pred_16x16.h264 -f framemd5 -y md5_neon
Signed-off-by: Bin Peng <pengbin@visionular.com>
(cherry picked from commit 3115c0c0e6)
Fix test failure on aarch64:
./tests/checkasm/checkasm --test=h264pred 367840
Signed-off-by: Peng Bin <pengbin@visionular.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 72a3656e84)
Fix test failure on aarch64:
./tests/checkasm/checkasm --test=h264pred 479612
The mismatch between neon and C functions can also be reproduced using the following bitstream and command line.
wget https://streams.videolan.org/ffmpeg/incoming/intra8x8pred_10bit.264
./ffmpeg -cpuflags 0 -threads 1 -i intra8x8pred_10bit.264 -f framemd5 -y md5_ref
./ffmpeg -threads 1 -i intra8x8pred_10bit.264 -f framemd5 -y md5_neon
Signed-off-by: Bin Peng <pengbin@visionular.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit decc9e643c)
On msys2, `uname -m` returns the architecture of the base msys2
layer. On Windows on arm64, the base msys2 layer itself is still
x86_64 only, even if running with e.g. the clangarm64 where the
windows native applications are built as aarch64.
If MSYSTEM_CARCH is set, use this instead of `uname -m` for
the default architecture. This gives the correct behaviour
for the clangarm64 environments. It also gives the correct
default for the 32 bit x86 environments such as `mingw32`.
(On `mingw32`, the fact that `uname -m` returned `x86_64`
hasn't been an issue, as both that and `i686` gets normalized
into `x86` internally in ffmpeg's configure.)
Signed-off-by: Coia Prant <coiaprant@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit df967d095a)
v2: test for function if AltiVec is enabled instead of with AltiVec and without VSX
(cherry picked from commit 49c8f33262)
Signed-off-by: Brad Smith <brad@comstyle.com>
Add a check for the existence of the vec_xl() function. Clang provides
the function even with VSX not enabled.
(cherry picked from commit 30a8641465)
Signed-off-by: Brad Smith <brad@comstyle.com>
Rather than just != 0. These values are read as uint32 and can become
negative when cast to int.
(cherry picked from commit eec1a7a6bb)
Signed-off-by: Anton Khirnov <anton@khirnov.net>
(cherry picked from commit 9cadadb9a1)
Signed-off-by: Anton Khirnov <anton@khirnov.net>
x265 added support for alpha starting with build 210.
While doing so, x265_encoder_encode() changed its fifth arg to
an array of pointers to x265_picture. This broke building lavc/libx265.c
This patch simply unbreaks the build and maintains existing single-layer
non-alpha encoding support.
Fixes#11130
Instead of relying on system #ifdefs which may or may not be correct,
detect the POSIX ioctl signature at configure time.
(cherry picked from commit 00b64fca55)
Signed-off-by: Brad Smith <brad@comstyle.com>
The detection logic for v4l2 and fbdev was accidentally modified to
depend on v4l2-m2m in 43b3412.
(cherry picked from commit 7405f1ad53)
Signed-off-by: Brad Smith <brad@comstyle.com>
Without resetting it, if there was a previous set of varstreams with
subtitles, it would subtract from all the streams, leading to chaos and
segfaults when trying to access for example stream -1.
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>
(cherry picked from commit c9151ea507)
Fields under the segmentation switch are never reset on a new frame, and
retain the value from the previous frame. This bugs out a bunch of
hwaccel drivers when segmentation is disabled but update_map isn't
reset because they don't ignore values behind switches. This commit also
resets the temporal field, though it may not be required.
We also do this for vp8 [1] so this commit is just mirroring the vp8
logic.
This fixes an issue with certain samples [2] that causes blocky
artifacts with vaapi, d3d11va and cuda (and possibly others).
Mesa worked around [3] this by ignoring these fields if
segmentation.enabled is 0, but d3d11va still displays blocky artifacts.
[1] 2e877090f9:/libavcodec/vp8.c#l797
[2] https://github.com/mpv-player/mpv/issues/13533
[3] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27816
Signed-off-by: llyyr <llyyr.public@gmail.com>
Regression since fd172185580c1ccdcfb90bbfdb59fa806fad3117;
triggered by vp4/KTkvw8dg1J8.avi in the FATE suite, but not
when running fate as this code is not used when the bitexact
flag is set.
Bisecting done by ami_stuff, patch from user Mika Fischer
in ticket #10027 (which this commit fixes).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit c3ca90a92e)
