Based on a patch by Hacene Bouaroua.
Fixes ticket #11171.
Co-authored-by: Hacene Bouaroua <hbouaroua@freebox.fr>
Signed-off-by: James Almer <jamrial@gmail.com>
Will be used to export certain information present in HEIF samples, like
rotation metadata, ICC profiles, and potentially others.
Signed-off-by: James Almer <jamrial@gmail.com>
Otherwise, things like ICC profiles as read from the colr box meant for an item
with no stream (like a grid) may end up being added to the wrong stream.
Signed-off-by: James Almer <jamrial@gmail.com>
The EXT-X-DISCONTINUITY tag was not being added to subtitle streams,
causing synchronization issues.i
This patch ensures that the tag is applied consistently across video and subtitle streams.
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
It's similar to av_get_frame_filename2 but with int64_t number
support. Make av_get_frame_filename* a wrapper over
ff_get_frame_filename.
Co-authored-by: Filip Mašić <shoutplenty@gmail.com>
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
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>