Fixes: signed integer overflow: 1073750247 * 2 cannot be represented in type 'int'
Fixes: 70722/clusterfuzz-testcase-minimized-ffmpeg_dem_ASF_O_fuzzer-5447231587549184
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
I encountered this problem with NTP timestamps that are extremely old,
like from January, 1990.
Although RFC3550 suggests that the timestamps in the RTCP packets use
the actual wallclock, some implementations use other clocks, such as
the CLOCK_MONOTONIC on linux.
I'm my case, I'm dealing with packets from mediasoup.
Without this patch, start_time_realtime shows up in the distance future
instead of around Jan 1900.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Fixes: signed integer overflow: 9223372036840103968 + 538976288 cannot be represented in type 'long'
Fixes: 70604/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-4844090340999168
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: signed integer overflow: 9223372036854775807 - -1927491430256034080 cannot be represented in type 'long'
Fixes: 70607/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-5282235077951488
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Tomas Härdin <git@haerdin.se>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: memeleak
Fixes: 70659/clusterfuzz-testcase-minimized-ffmpeg_dem_KUX_fuzzer-4539872627458048
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Steven Liu <lingjiujianke@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Make sure it's not zero, and equal or bigger than number of channels
Fixes: Timeout / DOS
Fixes: 67143/clusterfuzz-testcase-minimized-ffmpeg_dem_CAF_fuzzer-4858720481771520
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: James Almer <jamrial@gmail.com>
Player applications can now enjoy seeking while playing back
a title. Accuracy is at the mercy of what libdvdnav exposes,
which is currently dvdnav_time_search().
Signed-off-by: Marth64 <marth64@proxyid.net>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Now that mbedTLS 3.6.1 is released we know that only 3.6.0 contains this regression.
ref: c28e5b597e
Signed-off-by: sfan5 <sfan5@live.de>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
If the segment is very small, avformat_find_stream_info
will read all audio/video data in this segment.
cur->is_restart_needed is set to 0 later in dash_read_packet,
and no chance to be set to 1 again in the read_data function.
Reproduction:
ffmpeg -f lavfi -i mandelbrot -f lavfi -i anullsrc -c:v vp8 \
-g 5 -r 5 -c:a libopus -use_template 0 -seg_duration 1 \
-t 15 -y test_720.mpd
ffprobe -show_packets test_720.mpd
The time_base was a bad guess.
Currently, fate-time_base test data assumed that overriding the input
time_base would affect the frame_rate, but this behaviour is not
documented, so just fix the fate data now that this is fixed.
Fix regression since 10185e2d4c:
previously, when streamcopying, the time_base was guessed from the
frame_rate considering it is often constant, so guessing the frame_rate
back from the time_base was often not a problem.
To reproduce:
ffmpeg -i fate-suite/mpeg2/dvd_still_frame.vob -an -c copy out.mxf
Signed-off-by: Nicolas Gaullier <nicolas.gaullier@cji.paris>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
If the demuxer does not provide per-stream indexes, the generic seek search can
attempt to read the whole media file from the beginning when seeking. For large
MXF files this can cause huge lockups for a seek after the last timestamp,
which will eventually fail. So let's disable the generic seek for mxf, the
demuxer's own seek code should handle seeking just fine.
Signed-off-by: Marton Balint <cus@passwd.hu>
Recently, I have been experiencing an increasing number of user that use ffmpeg
to retrive RTSP stream from personal mediaproxies (e.g. MediaMtx) with
authorization based on JWT. The current length of PATH does not permit to
insert the token in the URL failing the authorization with no possibilities to
get the video.
VLC has just modified the RSTP max URL length, and it permits to use token
inside the URL.
For these reasons, I propose this patch to extend the PATH buffer from 1024 to
2048 in order to use tokens and the authorization process based on JWT.
Signed-off-by: Marton Balint <cus@passwd.hu>
The ret value here is not yet intialized so the return would return
uninitialized data. What was probably meant to be checked here was the
return value of ffio_read_size, which can return an error.
Introduced in 38bcb3ba7b
Fixes: CID1618758
Signed-off-by: James Almer <jamrial@gmail.com>
The output of put_bits_left() here can be as big as 27, which is a bit
count not supported by get_bits().
Fixes fate-iamf-stereo-demux when using --assert-level=2
Signed-off-by: James Almer <jamrial@gmail.com>
Use ff_mp4_read_descr() to read both the tags and the vlc value
that comes after it, which was not being taken into account.
Ref: https://github.com/AOMediaCodec/libiamf/issues/119
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: use of uninitialized value
Fixes: 70901/clusterfuzz-testcase-minimized-ffmpeg_dem_MV_fuzzer-6341913949569024
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: Use of uninitialized value
Fixes: 71280/clusterfuzz-testcase-minimized-ffmpeg_dem_ARGO_BRP_fuzzer-4692991866896384
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: Use of uninitialized value
Fixes: 71074/clusterfuzz-testcase-minimized-ffmpeg_IO_DEMUXER_fuzzer-5697034877730816
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: use of uninitialized value
Fixes: 70929/clusterfuzz-testcase-minimized-ffmpeg_dem_IAMF_fuzzer-5931276639469568
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Found by fuzzer.
Bug: https://crbug.com/356720789
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This results in an unnecessary ~800k allocation with H.264. A
nearby callsite uses avcodec_is_open() to avoid this, so do the
same when exiting avformat_find_stream_info().
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
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.
Fixes: use of uninitialized value
Fixes: 70872/clusterfuzz-testcase-minimized-ffmpeg_dem_OBU_fuzzer-6005782487826432
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: use of uninitialized value
Fixes: 70871/clusterfuzz-testcase-minimized-ffmpeg_dem_SEGAFILM_fuzzer-5883617752973312
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
These consts are only used in the switch(planar) case located in
avisynth_create_stream_video and nowhere else in the demuxer,
so move them into that function directly.
Signed-off-by: Stephen Hutchinson <qyot27@gmail.com>
As part of this, the mutexes are no longer necessary, and
avisynth_read_close needs to check that avs->avs_library.library
still exists before it attempts to call avisynth_context_destroy
and dlclose.
Signed-off-by: Stephen Hutchinson <qyot27@gmail.com>
The atexit() handler in the avisynth demuxer was added because
there was a conflict in AvxSynth that arose due to their use
of C++ global objects, particularly in relation to having
added a logging function relying on log4cpp.
This conflict was responsible for causing a segfault on exit.
It did not affect Windows with the (at the time) upstream
AviSynth 2.5 and 2.6, nor does it affect AviSynth+.
Unfortunately, none of this was actually shielded by ifdefs
indicating the fact it was only needed for AvxSynth, so four
years ago when AviSynth+ replaced AvxSynth as the handler
for AviSynth scripts on Unix-like OSes, the fact that the
atexit handler was no longer necessary was overlooked.
Signed-off-by: Stephen Hutchinson <qyot27@gmail.com>
