Fixes use of uninitialized value, reported by MSAN.
Found by OSS-Fuzz.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Fixes: 70852/clusterfuzz-testcase-minimized-ffmpeg_IO_DEMUXER_fuzzer-5179190066872320
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 5dfc0cc841)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes use of uninitialized value, reported by MSAN.
Found by OSS-Fuzz.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Fixes: 70837/clusterfuzz-testcase-minimized-ffmpeg_dem_JPEGXL_ANIM_fuzzer-5089407768526848
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 2b5f000d3f)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This fixes mixing up contexts, use of uninitialized data and crashes.
More specifically:
==1001752== Conditional jump or move depends on uninitialised value(s)
==1001752== at 0xA9ED82: avpriv_h264_has_num_reorder_frames (h264dec.c:64)
==1001752== by 0x668C7E: has_decode_delay_been_guessed (demux.c:757)
==1001752== by 0x66AB13: compute_pkt_fields (demux.c:1137)
==1001752== by 0x66B2E9: parse_packet (demux.c:1265)
==1001752== by 0x66BD84: read_frame_internal (demux.c:1449)
==1001752== by 0x67085B: avformat_find_stream_info (demux.c:2692)
==1001752== by 0x25157C: ifile_open (ffmpeg_demux.c:1814)
==1001752== by 0x272B15: open_files (ffmpeg_opt.c:1366)
==1001752== by 0x272D85: ffmpeg_parse_options (ffmpeg_opt.c:1415)
==1001752== by 0x2925C9: main (ffmpeg.c:991)
==1001752== Uninitialised value was created by a heap allocation
==1001752== at 0x483E0F0: memalign (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==1001752== by 0x483E212: posix_memalign (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==1001752== by 0x14882CE: av_malloc (mem.c:107)
==1001752== by 0x1463785: av_buffer_alloc (buffer.c:82)
==1001752== by 0x146423F: pool_alloc_buffer (buffer.c:369)
==1001752== by 0x14643C4: av_buffer_pool_get (buffer.c:407)
==1001752== by 0x752C4B: buffer_pool_get (mpegts.c:1142)
==1001752== by 0x7538F2: mpegts_push_data (mpegts.c:1407)
==1001752== by 0x758893: handle_packet (mpegts.c:2909)
==1001752== by 0x758E90: handle_packets (mpegts.c:3048)
==1001752== by 0x759B1D: mpegts_read_packet (mpegts.c:3290)
==1001752== by 0x6687A3: ff_read_packet (demux.c:649)
==1001752== by 0x66B594: read_frame_internal (demux.c:1346)
==1001752== by 0x67085B: avformat_find_stream_info (demux.c:2692)
==1001752== by 0x25157C: ifile_open (ffmpeg_demux.c:1814)
==1001752== by 0x272B15: open_files (ffmpeg_opt.c:1366)
==1001752== by 0x272D85: ffmpeg_parse_options (ffmpeg_opt.c:1415)
==1001752== by 0x2925C9: main (ffmpeg.c:991)
Found-by: Alexander A. Shvedov <shvedov@gmx.com>
CC: Pavel Koshevoy <pkoshevoy@gmail.com>
This reverts commit 0021484d05.
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)
I have several .ts captures where video and audio codec changes even
though the PMT version does not change and the PIDs stay the same.
This happens during transition to/from slate (mpeg2 video and audio)
to network broadcast (hevc video and eac3 audio in private PES).
I've updated fate ts-demux expected results.
Codec probing was primarily added to the wav demuxer to support DTS-in-wav
files, but DTS probing functions return AVPROBE_SCORE_EXTENSION+1, so we can be
a bit more strict with the required score.
This fixes MP3 misdetections for some wav files.
Fixes ticket #11581.
Signed-off-by: Marton Balint <cus@passwd.hu>
(cherry picked from commit ce01c7fb58)
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>
Traditionally, macOS has shipped an old version of rsync that lacked
support for this option, hence this check (added in
a8b3f0c5cf).
However, in macOS 15.x, Apple have switched to providing rsync as a
different tool, openrsync. The version of openrsync in at least
macOS 15.2 does include "[--contimeout]" (note the lack of "=" after
the option), in the output of "rsync --help", but when used, the tool
errors out with "rsync: --contimeout=60: unknown option". So apparently
the tool erroenously lists the option as supported, while it really
isn't.
The original rsync tool (with a new enough version) prints
"--contimeout=SECONDS" in the output of "rsync --help".
It is unclear which version of openrsync Apple are shipping; the latest
upstream openrsync from OpenBSD does support the option and includes
"[--contimeout=seconds]" in the output of "--help", and older versions
don't seem to include the option as listed at all.
Therefore, check for "--conntimeout=" with the "=", this should
properly detect both new enough rsync and openrsync.
This fixes running "fate-rsync" on macOS 15.x.
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 3cd4e8470a)
When running the cleanup in rtmp_close on failures in rtmp_open,
we can in rare cases end up using rt->playpath, assuming that it
is still set.
The crash could happen if we hit the fail codepath in rtmp_open
while publishing (rt->is_input == 0) with rt->state set to
a value > STATE_FCPUBLISH.
This would normally not happen while publishing; either we have
an error (and rt->state <= STATE_FCPUBLISH) or we reach
rt->state = STATE_PUBLISHING, and then we also return successfully
from rtmp_open.
The unexpected combination of states could happen if the server
responds with e.g. "NetStream.Play.Stop" while expecting
"NetStream.Publish.Start"; this sets rt->state to STATE_STOPPED,
which also fulfills the condition "> STATE_FCPUBLISH".
We don't need to free the rt->playpath/tcurl/flashver strings here;
they're handled via AVOption, and thus are freed automatically when
the protocol instance is freed (that's why they aren't freed
manually within the rtmp_close function either).
We also don't need to free the AVDictionary with options; it's
owned by the caller.
A smaller fix would be to just call rtmp_close before freeing
the strings and dictionary, but as we don't need to free them
at all, let's remove that redundant code.
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 8f4819ce01)
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)
The arm/aarch64 horizontal filter reads one additional pixel beyond what
the filter uses. This can become an issue if the application does not
allocate larger buffers than what's required for the pixel data. If the
motion vector points to the bottom right edge of the picture this
becomes a read buffer overflow. This triggers segfaults in Firefox for
video resolutions which result in a page aligned picture size like
1280x640.
Prevent this by using emulated edge in this case.
Fixes: https://bugzilla.mozilla.org/show_bug.cgi?id=1881185
Signed-off-by: Janne Grunau <janne-ffmpeg@jannau.net>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
(cherry picked from commit 060464105b)
This reduces the amount the horizontal filters read beyond the filter
width to a consistent 1 pixel. The data is not used so this is usually
not noticeable. It becomes a problem when the application allocates
frame buffers only for the aligned picture size and the end of it is at
a page boundary. This happens for picture sizes which are a multiple of
the page size like 1280x640. The frame buffer allocation is based on
its most likely done via mmap + MAP_ANONYMOUS so start and end of the
buffer are page aligned and the previous and next page are not
necessarily mapped.
This mirrors the aarch64 change.
Signed-off-by: Janne Grunau <janne-ffmpeg@jannau.net>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
(cherry picked from commit f366256215)
This reduces the amount the horizontal filters read beyond the filter
width to a consistent 1 pixel. The data is not used so this is usually
not noticeable. It becomes a problem when the application allocates
frame buffers only for the aligned picture size and the end of it is at
a page boundary. This happens for picture sizes which are a multiple of
the page size like 1280x640. The frame buffer allocation is based on
its most likely done via mmap + MAP_ANONYMOUS so start and end of the
buffer are page aligned and the previous and next page are not
necessarily mapped.
Under these conditions like seen by Firefox a read beyond the end of the
buffer results in a segfault.
After the over-read is reduced to a single pixel it's reasonable to use
VP9's emulated edge motion compensation for this.
Fixes: https://bugzilla.mozilla.org/show_bug.cgi?id=1881185
Signed-off-by: Janne Grunau <janne-ffmpeg@jannau.net>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
(cherry picked from commit 430c38f698)
This should fix the build on LLVM 16 and earlier, at the cost of turning
all non-RVV optimisations off.
(cherry picked from commit b3825bbe45)
Signed-off-by: Brad Smith <brad@comstyle.com>
The logic did not follow the documented behaviour and that caused skipping of
some audio in the loop and in the leftover buffer.
Example command line which should produce a smooth sine wave for the whole
duration of the output:
ffmpeg -f lavfi -i "sine=r=48000:f=480:d=4" -af "aloop=loop=4:start=48000:size=48000" out.wav
Fixes ticket #11283.
Signed-off-by: Marton Balint <cus@passwd.hu>
(cherry picked from commit fe18ed3f2a)
If the audio loop stops inside an audio frame, the leftover buffer contains the
end of the frame, which is not looped. The length supposed to be the part which
was not written to the loop buffer, so we need to drain exactly that number of
bytes from the leftover buffer.
Signed-off-by: Marton Balint <cus@passwd.hu>
(cherry picked from commit b33a594160)
The JPEG XL parser has an entropy decoder inside, which supports LZ77
length-distance pairs. If the first symbol from the entropy stream is an
LZ77 pair, the bitstream is invalid, so we should abort immediately rather
than attempt to read it anyway (which would read from the uninitialized
starting window).
Reported-by: Kacper Michajłow <kasper93@gmail.com>
Found-by: ossfuzz
Fixes: 368725676/clusterfuzz-testcase-minimized-fuzzer_protocol_file-6022251122589696-cut
Fixes: 42537758/clusterfuzz-testcase-minimized-fuzzer_protocol_file-5818969469026304-cut
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Fixes compile error on windows with decklink:
In file included from ./libavformat/os_support.h:175,
from ./libavformat/internal.h:30,
from libavdevice/decklink_common.cpp:25:
./libavutil/wchar_filename.h: In function 'int wchartocp(unsigned int, const wchar_t*, char**)':
./libavutil/wchar_filename.h:59:32: error: invalid conversion from 'void*' to 'char*' [-fpermissive]
59 | *filename = av_malloc_array(num_chars, sizeof **filename);
| ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| void*
Regression since e9e8bea2e7.
Fixes ticket #11103.
Signed-off-by: Marton Balint <cus@passwd.hu>
(cherry picked from commit 9b0128aa76)
Earlier, x265 made an API change to support alpha and
other multiple layer pictures. We added guards to accommodate
that in 1f801dfdb5
They have now reverted that API change in
78e5b703b1
Updated our wrapper guards to unbreak build again.
Fixes#10887
(cherry picked from commit 536bb98888)
Signed-off-by: Anton Khirnov <anton@khirnov.net>
(cherry picked from commit f705bc5b73)
Signed-off-by: Anton Khirnov <anton@khirnov.net>
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.
binutils 2.43 has stricter validation for labels[1] and results in errors
when building ffmpeg for armv5:
src/libavcodec/arm/mlpdsp_armv5te.S:232: Error: junk at end of line, first unrecognized character is `0'
Remove the leading zero in the "01" label to resolve this error.
[1] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=226749d5a6ff0d5c607d6428d6c81e1e7e7a994b
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
(cherry picked from commit 654bd47716)
Fixes: out of array access
Fixes: 70741/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-5703668010647552
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 06f5ed40f8)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The snow encoder uses block based motion estimation which can read out of array if
insufficient alignment is used
It may be better to only apply this for the encoder, as it would safe a few bytes of memory
for the decoder. Until then, this fixes the issue in a simple way.
Fixes: out of array access
Fixes: 68963/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-4979988435632128
Fixes: 68969/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-6239933667803136.fuzz
Fixed: 70497/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SNOW_fuzzer-5751882631413760
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 58fbeb59e7)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
We currently write invalid sBIT entries for indexed PNGs, which by PNG
specification[1] must be 3-bytes long. The values also are capped at 8
for indexed-color PNGs, not the palette depth. This patch fixes both of
these issues previously fixed in the decoder, but not the encoder.
[1]: https://www.w3.org/TR/png-3/#11sBIT
Regression since: c125860892.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Reported-by: Ramiro Polla: <ramiro.polla@gmail.com>
The PNG specification[1] says that sBIT entries must be at most the bit
depth specified in IHDR, unless the PNG is indexed-color, in which case
sBIT must be between 1 and 8. We should not reject valid sBITs on PNGs
with indexed color.
[1]: https://www.w3.org/TR/png-3/#11sBIT
Regression since 84b454935f.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Reported-by: Ramiro Polla <ramiro.polla@gmail.com>
Commit 4ef5e7d472 add qmin/qmax support to videotoolbox encoder.
The default value of (qmin, qmax) is (2, 31), which makes bitrate
control doesn't work as users' expectations.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
(cherry picked from commit d07da7539d)
The search of the current DirectShow device list has been customized so
that audio devices are always found even if no video device is connected.
Signed-off-by: Jens Frederich <jens.frederich@vector.com>
Reviewed-by: Roger Pack <rogerdpack2@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 60b1750134)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This needs to be double checked or a checking way of writing should be used
Fixes: out of array access
Fixes: 70007/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HDR_fuzzer-5478704150020096
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 204f7f8cc7)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: out of array access
Fixes: 68941/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-5990952685600768
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 5dde255abd)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: -35511773 * 256 cannot be represented in type 'int'
Fixes: 70406/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_OSQ_fuzzer-6545326804434944
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 6420c1bf30)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: 2.96539e+09 is outside the range of representable values of type 'int'
Fixes: Assertion n>=0 && n<=32 failed at libavcodec/get_bits.h:423
Fixes: 62241/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_OSQ_fuzzer-4525761925873664
Fixes: 70406/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_OSQ_fuzzer-6545326804434944
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 56c334d732)
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
