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)
src/libavcodec/mips/cabac.h:160:77: error: instruction requires a CPU feature not currently enabled
160 | PTR_SUBU "%[tmp1], %[c_low], %[tmp1] \n\t"
| ^
<inline asm>:13:2: note: instantiated into assembly here
13 | movz $15, $13, $24
| ^
OpenBSD targets MIPS III ISA.
Signed-off-by: Brad Smith <brad@comstyle.com>
(cherry picked from commit 9432f85830)
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)
They are optional and just define a channel layout, which may also be defined
by the underlying codec.
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit 95fe0658d7)
Needed to keep the process going if some issue was found while parsing these boxes.
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit fd1c8fa0e6)
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 ticket #22890.
The ff_hls_senc_parse_audio_setup_info function passes setup_data to
parsers like avpriv_ac3_parse_header and init_get_bits8 which require
the buffer to be padded with AV_INPUT_BUFFER_PADDING_SIZE bytes at the end.
(cherry picked from commit 71d5fa8d4d)
Signed-off-by: Marvin Scholz <epirat07@gmail.com>
Write the 24-bit vpcC flags field at the current cursor position after
the version byte. The previous code wrote to p+1 instead of p, leaving
one byte uninitialized between version and flags and shifting all
subsequent fields (profile, level, bitdepth, etc.) by one byte.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
(cherry picked from commit 19c4bcae68a16ea893b0558d720dd4a2ecd58f0f)
Return the actual find_sei_end() error when SEI appending fails instead of
reusing the previous status code. This preserves the real parse failure for
callers instead of reporting malformed SEI handling as success.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
(cherry picked from commit f7c04283367269c7aef2505a1839fb3ea9362330)
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>
Given the entire iamf struct is inside a single Track, if the first iamf stream
(which is the one sharing the index and id from the Track) was to be disabled,
then packets from every iamf stream would be discarded.
Fix this by actually going through the entire iamf Sample and discarding those
from the disabled streams only.
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit 16ee3d8d99)
If we were to add the highest id of a non iamf stream as offset to iamf stream
ids, and one of the latter was 0, then an id overlap would ocurr.
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit 51aef95ba1)
Using audio_substream_id for AVStream ids is not ideal give that in containers
like mp4, the IAMF structure is opaque to the outside and other streams may
share such id values.
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit a8f2374507)
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)
After the full ffmpeg CLI multithreading changes went in, this
test started depending on how far the input side read and decoded
the input compared to how quickly the output encoded things, causing
spurious failures on the CI.
To my knowledge all of the failures have so far been valid correct
results, but unfortunately FATE's built in checks mostly consist of
whether there is a difference against an exact result.
This way we still get the CI and valgrind running of the code,
but stop its comparison. Reference file is left around so that
the previous reference is still available.
(cherry picked from commit e54bd7065d)
Fixes an issue in the previous commit where I forgot that 7.x still had the
distinction between the src and src_sched nodes; which was later removed.
Fixes: d65d34d656
When the furthest-behind stream is being fed by a demuxer that is also
feeding packets to a choked filter graph, we need to unchoke that filter
graph to prevent the demuxer from getting stuck trying to write packets to
the choked filter graph.
This situation can also apply recursively - if the demuxer is also writing
to a filtergraph that is also reading from a choked demuxer, there is a
similar deadlock.
Solve all such deadlocks by just brute-force recursively unchoking all
nodes that can somehow prevent this demuxer from writing packets. This
should normally not result in any change in behavior, unless audio/video
streams are badly desynchronized, in which case it may result in extra
memory usage from the too-far-ahead stream buffering packets inside the
muxer. (But this is, of course, preferable to a deadlock)
---------
Backporting changes:
1. Replaced `SchDec.outputs` by `SchDec.dst`
2. Replace `av_unreachable()` by `av_assert0`
Fixes: https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/20611
Backported-From: 133a0bcb13
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)
- proper pts for packets. leaving it blank leaves it up for guessing,
but the guess doesn't take seeking into account, causing weirdness.
- clamp to 0 when seeking to negative ts. libopenmpt docs are unclear on
this but not doing this causes an immediate EOF when seeking backwards
to the beginning in mpv.
- only set song duration and packet pts when they are non-negative and
in int64 range. NaNs count as out of range. this isn't a fix for any
specific issue but might be helpful still, and shouldn't break
anything.
(cherry picked from commit ecef5f9e1f)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Apparently files with milliseconds exist in the wild. And since it cost
nothing to support arbitrary number of digits, extend format to support
that.
Depending on number of digits, the time base of fractional part is
changing. Most LRCs use 2 digits and centiseconds base, but subs with 3
digits and miliseconds exist too.
Set internal time base to AV_TIME_BASE, which in parcitice allows to
hold microseconds with 6 digits. Totally artificial, but who knows maybe
someone wants that.
Fixes: #11677
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
(cherry picked from commit bc3cc0a6af)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Slice threading remains available!
The race condition fix is in 8d5efc2182
and bcf08c1171
Backport of these is welcome
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Add check for the return value of avcodec_alloc_context3() to avoid potential NULL pointer dereference.
Fixes: 5d48e4eafa ("Merge commit 'a6a750c7ef240b72ce01e9653343a0ddf247d196'")
Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 55d234b433)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Add av_packet_free() to free avpkt_clone and avpkt in the error paths to avoid potential memory leak.
Fixes: da3c69a5a9 ("Added test for libavcodec/avpacket.c")
Signed-off-by: Jiasheng Jiang <jiashengjiangcool@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit ab040e2565)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
