6c7a344b65 made the VLCs shared between
threads and did so in a way that was designed to support stream
reconfigurations, so that the structure containing the VLCs was
synced in update_thread_context. The idea was that the currently
active VLCs would just be passed along between threads.
Yet this was broken by 5acbdd2264:
Before this commit, submit_packet() was a no-op during flushing
for VP3, as it is a no-delay decoder, so it won't produce any output
during flushing. This meant that prev_thread in pthread_frame.c
contained the last dst thread that update_thread_context()
was called for (so that these VLCs could be passed along between
threads). Yet after said commit, submit_packet was no longer
a no-op during flushing and changed prev_thread in such a way
that it did not need to contain any VLCs at all*. When flushing,
prev_thread is used to pass the current state to the first worker
thread which is the one that is used to restart decoding.
It could therefore happen that the decoding thread did not contain
the VLCs at all any more after decoding restarts after flushing
leading to a crash (this scenario was never anticipated and
must not happen at all).
There is a simple, easily backportable fix given that we do not
support stream reconfigurations (yet) when using frame threading:
Don't sync the VLCs in update_thread_context(), instead do it once
during init.
This fixes forgejo issue #20346 and trac issue #11592.
(I don't know why 5acbdd2264
changed submit_packet() to no longer be a no-op when draining
no-delay decoders.)
*: The exact condition for the crash is nb_threads > 2*nb_frames.
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 90551b7d80)
Currently, the thread loop of ffmpeg_filter essentially works like this:
while (1) {
frame, idx = get_from_decoder();
err = send_to_filter_graph(frame);
if (err) { // i.e. EOF
close_input(idx);
continue;
}
while (filtered_frame = get_filtered_frame())
send_to_encoder(filtered_frame);
}
The exact details are not 100% correct since the actual control flow is a bit
more complicated as a result of the scheduler, but this is the general flow.
Notably, this leaves the possibility of leaving a no-longer-needed input
permanently open if the filter graph starts producing infinite frames (during
the second loop) *after* it finishes reading from an input, e.g. in a filter
graph like -af atrim,apad.
This patch avoids this issue by always querying the status of all filter graph
inputs and explicitly closing any that were closed downstream; after each round
of reading output frames. As a result, information about the filtergraph being
closed can now propagate back upstream, even if the filter is no longer
requesting any input frames (i.e. input_idx == fg->nb_inputs).
Fixes: https://trac.ffmpeg.org/ticket/11061
See-Also: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20457#issuecomment-6208
Backported-from: 38a5fcc02c
During backporting, I had to change the signature of `close_input()` to
`void close_input(FilterGraph *fg, int input_idx)` since this version of
FFmpeg does not contain a reference to the input index in the InputFilterPriv.
There is currently no way for API users to know that a buffersrc is no longer
accepting input, except by trying to feed it a frame and seeing what happens.
Of course, this is not possible if the user does not *have* a frame to feed,
but may still wish to know if the filter is still accepting input or not.
Since passing `frame == NULL` to `av_buffersrc_add_frame()` is already treated
as closing the input, we are left with no choice but to introduce a new
function for this.
We don't explicitly return the result of `ff_outlink_get_status()` to avoid
leaking internal status codes, and instead translate them all to AVERROR(EOF).
Backported-from: 623669a02c
For GET_UTF8(val, GET_BYTE, ERROR), val has type of uint32_t,
GET_BYTE must return an unsigned integer, otherwise signed
extension happened due to val= (GET_BYTE), and GET_UTF8 went to
the error path.
This bug incidentally cancelled the bug where hb_buffer_add_utf8
was being called with incorrect argument, allowing drawtext to
function correctly on x86 and macOS ARM, which defined char as
signed. However, on Linux and Android ARM environments, because
char is unsigned by default, GET_UTF8 now returns the correct
return, which unexpectedly revealed issue #20906.
(cherry picked from commit a5cc0e5c9e)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
From the doc of HarfBuzz, what hb_buffer_add_utf8 needs is the
number of bytes, not Unicode character:
hb_buffer_add_utf8(buf, text, strlen(text), 0, strlen(text));
Fix issue #20906.
(cherry picked from commit 9bc3c572ea)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
packet_buffer is used in mux.c, and if a muxing process fails at a point where
packets remained in said queue, they will leak.
Fixes ticket #11419
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit c08d300481)
update the switch statement for EXR_UINT in pxr24_uncompress to
correctly use the tile width td->xsize instead of using the full window
width s->xdelta. s->delta is larger than td->xsize which lead to two
buffer overflows when interacting with the ptr variable in the same
switch statement.
Fixes: out of bounds read and write
Found-by: veygax's insomnia network (INSOMNIA-1)
Signed-off-by: veygax <veyga@veygax.dev>
(cherry picked from commit 162f75b5e6)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The existing is_luma check is fragile as depending on the order
of channels it can be set or reset
No testcase
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 6e8cf0377f)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: use of uninitialized memory
Fixes: 427814450/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MAGICYUV_DEC_fuzzer-646512196065689
Fixes: 445961558/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_UTVIDEO_DEC_fuzzer-5515158672965632
the multi vlc code will otherwise return uninitialized data. Now one can argue that this data should
not be used, but on errors this data can remain ...
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit d8ffec5bf9)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The implementation hardcodes access to 3 channels, so we need to check that
Fixes: out of array access
Fixes: BIGSLEEP-445394503-crash.exr
Found-by: Google Big Sleep
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 7896cc67c1)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array read
Fixes: dwa_uncompress.py.crash.exr
The code will read from the ac data even if ac_size is 0, thus that case
is not implemented and we ask for a sample and error out cleanly
Found-by: Google Big Sleep
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 8e078826da)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Without rounding them up there are too few dc coeffs for the blocks.
We do not know if this way of handling odd dimensions is correct, as we have
no such DWA sample.
thus we ask the user for a sample if she encounters such a file
Fixes: out of array access
Fixes: BIGSLEEP-445392027-crash.exr
Found-by: Google Big Sleep
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit c911e00011)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Otherwise it might be > buf_ptr in which case ffio_get_checksum()
could segfault (s->buf_ptr - s->checksum_ptr would be negative
which would be converted to something very big when converted
to unsigned for the update_checksum callback).
Fixes ticket #11233.
Reported-by: Du4t
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(cherry picked from commit 987c955cd7)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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)
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)
If avctx->ch_layout is unset (as it's allowed and even expeced by the
AV_CODEC_CAP_CHANNEL_CONF flag), the code setting substream masks will fail for
stereo and mono layouts unless a downmix channel was requested.
Fix this by deriving the mask with coded values only.
Fixes issue #20764.
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit 530ca627a3)
The parser API doesn't work with packets, only raw data, so in order for it to
be made aware of new extradata propagated through packet side data we need to
pass it in some other form, namely, replacing the main extradata and ensuring
it will be parsed by restarting the parser.
Signed-off-by: James Almer <jamrial@gmail.com>
This was disabled in da60b99a88 and then
accidentally re-enabled in 172b0e2e88.
The code in question was never properly adapted for litte-endian mode.
refs: trac/10955
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 4322be512b)
Rename the HWCAP defines to use the same naming scheme as AArch64 and PPC.
(cherry picked from commit ced4a6ebc9)
Signed-off-by: Brad Smith <brad@comstyle.com>
- FreBSD/OpenBSD have elf_aux_info() on arm
- Wrap AT_HWCAP as the value is different for BSD vs Linux (16 vs 25)
(cherry picked from commit cdae5c3639)
Signed-off-by: Brad Smith <brad@comstyle.com>
Regression since 5acbdd2264, which removed
setting both values from PerThreadContext.
Given the pthread code calls ff_decode_receive_frame_internal() on the frame,
any value set before it will be overwritten, so instead sync each thread's
DecodeContext and let ff_decode_receive_frame_internal() handle these values.
Fixes issue #20534.
Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit 26f4230082)
