Version 1.1 (FX Fighter) files all have a sample rate of 44100
in the header, but only play back correctly at 22050.
Force the sample rate to 22050 when reading, and restrict it
when muxing.
Fixes: signed integer overflow: 7958120835074169528 * 9 cannot be represented in type 'long long'
Fixes: 23382/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-6230683226996736
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Currently the utilized AVBPrint API is internally limited to unsigned
integers, so if we limit the file size as well as the amount to read
to UINT_MAX - 1, we do not require additional limiting to be performed
on the values.
This change is based on the fact that initially the 8*1024 value added
in 96d70694aea64616c68db8be306c159c73fb3980 was only for the case where
the file size was not known. It was not a maximum file size limit.
In 29121188983932f79aef8501652630d322a9974c this was reworked to be
a maximum manifest file size limit, while its commit message appears
to only note that it added support for larger manifest file sizes.
This should enable various unfortunately large MPEG-DASH manifests,
such as Youtube's multi-megabyte live stream archives to load up
as well as bring back the original intent of the logic.
YUV4MPEG writes a string as header for both the file itself as well as
for every frame; these strings contain magic strings and these were up
until now included in the string to write via %s. Yet they are compile
time constants, so one can use the compile-time string concatentation
instead of inserting these strings at runtime.
Furthermore, the global header has been written via snprintf() to
a local buffer first before writing it. This can be simplified by using
avio_printf().
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This also changes a check for mfra_size from < 0 to == 0, since
it was always wrong, as avio_rb32 returns an unsigned integer.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
On files with more than one sidx box, like live fragmented MP4
files, it was previously re-reading and seeking on every singl
sidx box, leading to extremely poor performance on larger files,
especially over the network.
Only do it on the first one, and stash its result.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
It should be a 64-bit integer, otherwise it overflows and fails
on files greater than 2GB on some systems like x86_64 Linux.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
In ticket #8754 there is discourse surrounding the error
message which is printed upon a mismatched aspect ratio in
derived encodings. This should make it clearer to the user
as to the issues which they are experiencing.
Reviewed-by: "Jeyapal, Karthick" <kjeyapal@akamai.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
MXF CDCI color range was being set to (1<<sc->component_depth) - 1
for full range but it should be (1<<sc->component_depth) as 0 is
a valid value.
Signed-off-by: Harry Mallon <harry.mallon@codex.online>
A few popular sites have started generating MP4 files which have a
sidx plus an mfra. The sidx accounts for all size except the mfra,
so the old code did not mark the fragment index as complete.
Instead we can just check if there's an mfra and if its size makes
up the difference we can mark the index as complete.
Bug: https://crbug.com/1107130
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Some DVB and ATSC captures are using the official MPEG2 registration
descriptor in addition to using the correct stream type and the
AC-3_audio_stream_descriptor/AC3_descriptor. So let's add it even if it is not
strictly needed for DVB/ATSC.
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
It help initialize chroma format and other info properly
Chroma format wasn't correct if I use below code:
avformat_find_stream_info(fmtc, NULL);
iVideoStream = av_find_best_stream(fmtc, AVMEDIA_TYPE_VIDEO, -1, -1, NULL, 0);
eChromaFormat = (AVPixelFormat)fmtc->streams[iVideoStream]->codecpar->format;
Signed-off-by: James Almer <jamrial@gmail.com>
Check the return value of sscanf as it can return -1(EOF), for example
when the first char in the line is 0x00
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
ffmpeg documentation says the NUT container supports SubStation Alpha
This brings actual functionality in line with documentation.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The write_colr flag has been marked as experimental for over 5 years.
It should be safe to enable its behavior by default as follows:
- Write the colr atom by default for mp4/mov if any of the following:
- The primaries/trc/matrix are all specified, OR
- There is an ICC profile, OR
- The user specified +write_colr
- Keep the write_colr flag for situations where the user wants to
write the colr atom even if the color info is unspecified (e.g.,
http://ffmpeg.org/pipermail/ffmpeg-devel/2020-March/259334.html)
This fixes https://trac.ffmpeg.org/ticket/7961
Signed-off-by: Michael Bradshaw <mjbshaw@google.com>
In listener mode the first fd is not closed when libsrt_close() is called
because it is overwritten by the new accept fd. Added the listen_fd to the
context to properly close it when libsrt_close() is called.
Fixes trac ticket #8372.
Signed-off-by: Nicolas Sugino <nsugino@3way.com.ar>
Signed-off-by: Marton Balint <cus@passwd.hu>
Fixes: Assertion failure
Fixes: 24612/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-6600899842277376.fuzz
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
While reading the filename tag, it may return a EOF and we are still
copying the file with uninitialized value.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
While having the possibility of non-NOPTS values that can suddenly
jump in time due to adjustments to match PCR is not nice for DVB
subtitles, apparently the parser for this format bases its behavior on
whether the packets' timestamps are NOPTS or not. Thus while we can
adjust timestamps, we should exclude DVB subtitles from the timestamp
unsetting logic.
Fixes#8844
Otherwise it might happen that invalid dimensions are used when reading
a video packet; this might lead to undefined overflow.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The mlv demuxer supports input split into multiple files; if invalid
data is encountered when parsing one of the subsequent files, that file
is closed. But at this point some index entries belonging to this file
might already have been added. In this case, the read_packet function
might try to use the AVIOContext (which is NULL) to read data which will
of course crash. This commit fixes this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
and remove reset_packet(). The packet's data pointer is already zeroed,
so the only thing that reset_packet() does that av_init_pkt() doesn't is
redundant.
Reviewed-by: Steven Liu <lingjiujianke@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
av_read_frame() already returns blank packets on error.
Reviewed-by: Steven Liu <lingjiujianke@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If avio_read() returns a value of bytes read that's lower than the
expected, return an error instead. And when there are zero bytes in
the prefetch buffer, return 0 in order for the frame merge bsf to
drain all potentially buffered packets.
Missed by mistake when amending and committing 9a7bdb6d71.
Signed-off-by: James Almer <jamrial@gmail.com>
