Just postpone the allocation of the dict until it is really needed
(after the checks that can fail).
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This currently doesn't cause any trouble, because the only caller did
not clean up the representation upon error at all; but fixing this is
a prerequisite for doing so.
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The code in question seems to have been copied from about 70 lines
above; yet the code here is only executed if some of the variables
(namely representation_segmenttemplate_node and fragment_template_node)
are NULL, so it makes no sense to check them for a child element.
Also remove a redundant resetting of a pointer to an AVFormatContext
after avformat_close_input() (which already sets the pointer to NULL).
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
When using one of the AV_DICT_DONT_STRDUP_KEY/VAL flags, av_dict_set()
already frees the key/value on error, so that freeing it again would
lead to a double free.
Reviewed-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The AAX demuxer reads a 32bit number containing the amount of entries
of an array and stores it in an uint32_t. Yet when iterating over this
array, a loop counter of type int is used. This leads to undefined
behaviour if the amount of entries is not in the range of int; to avoid
this, it is generally good to use the same type for the loop counter as
for the variable it is compared to. This is done in one of the two loops
affected by this.
In the other loop, the undefined behaviour can begin even earlier: Here
the loop counter is multiplied by an uint16_t which can overflow as soon
as the loop counter is > 2^15. Using an unsigned type would avoid the
undefined behaviour, but truncation would still be possible, so use an
uint64_t.
Also use an uint32_t for a variable containing an index in said array.
This fixes Coverity issue #1466767.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
There was almost no overlap between them: The only field used by both
was an int named samples_per_frame. Therefore this commit separates
them.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The tedcaptions demuxer uses an AVBPrint whose string is not restricted
to its internal buffer; it therefore needs to be cleaned up, yet this is
not done on error, as parse_file() returned simply returned directly.
This is fixed by going to fail first in such cases.
Furthermore, there is also a second way how this string can leak: By
having more than one subtitle per subtitle block, as the new one simply
overwrites the old one in this case as the AVBPrint is initialized each
time upon encountering a subtitle line. The code has been modified to
simply append the new subtitle to the old one, so that the old one can't
leak any more.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Turns out that there are files with multiple (reasonably-sized) BASF
blocks. Some of the files just have particularly large frames (~10s).
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
Enforcing num_chunks == 1 only makes sense when demuxing from an ASF
file. When embedded in a BRP file, an ASF stream can have multiple chunks.
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
The SWF muxer accepts at most one mp3 audio and at most one VP6F, FLV1
or MJPEG stream. Upon encountering an mp3 stream, a fifo is allocated
that leaks if one of the subsequent streams is incompliant with the
restrictions mentioned above or if the framerate or samplerate are
invalid. This is fixed by adding a deinit function to free said fifo.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The RealMedia demuxer uses the priv_data of its streams to store a
structure containing an AVPacket. These packets are unreferenced in the
read_close function, yet said function simply presumed that the
priv_data has been successfully allocated. This implies that it mustn't
be called when an allocation of priv_data fails; but this can happen
since commit 35bbc1955a if one has a
stream with multiple substreams (also exported as AVStream) and if
allocating the priv_data for one of these substreams fails.
This has been fixed by making sure that read_close can handle the case
in which priv_data has not been successfully allocated.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The RealMedia demuxer's read_header function initially initializes ret,
the variable designated for the return variable to -1. Afterwards, chunks
of the file are parsed in a loop until an error happens or until the actual
frame data is encountered. If the first function whose return
value is put into ret doesn't fail, then ret contains a value >= 0
(actually == 0) and this is what will be returned if an error is
encountered afterwards.
This is a regression since 35bbc1955a.
Before that, ret had never been overwritten with a nonnegative value.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Garbage was left-over in the ArgoASFFileHeader::name field if the url
was too short. This zero-initialises it.
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
And replace the flags parameter with a function callback that can be used to
copy the contents of the packet (e.g, av_packet_ref and av_packet_copy_props).
Signed-off-by: James Almer <jamrial@gmail.com>
Used in FMVs for FX Fighter and Croc. Supports BVID and BASF streams,
requests samples for anything else.
Due to the way BASF streams are contained in the file, only one is
supported. I have yet to see a BRP file with multiple.
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
Fixes: signed integer overflow: 8398407 * 300 cannot be represented in type 'int'
Fixes: 23914/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-4702539290509312
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Instead move the extradata contained in packet side-data to its
destination. This is possible because the side data already has zeroed
padding.
Notice that the check for FF_MAX_EXTRADATA_SIZE has been dropped,
because said constant is from libavcodec/internal.h. If libavcodec
wanted to enforce this, it should do so in the extract_extradata BSF
instead.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This code mostly duplicates code in the deinit function; the only
exception is av_opt_free(): The options are freed generically lateron.
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This fixes leaks when the trailer is never written.
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
seg_init() and seg_write_header() currently contain a few error paths
in which an already opened AVIOContext for the child muxer leaks (namely
if there are unrecognized options for the child muxer or if writing the
header of the child muxer fails); the reason for this is that this
AVIOContext is not closed in the deinit function. If all goes well, it
is closed when writing the trailer. From this it also follows that the
AVIOContext also leaks when the trailer is never written, even when
writing the header succeeds.
But simply freeing said AVIOContext in the deinit function is
complicated by the fact that the AVIOContext may or may not have been
opened via the io_open callback: If options are set to discard header
and trailer, said AVIOContext can also be a null context which must not
be closed via the io_close callback. This may lead to crashes, as
io_close may presume the AVIOContext's opaque to be set. It currently
works with the default io_close callback which simply calls avio_close(),
because avio_close() doesn't care about opaque being NULL since commit
6e8e8431e1. Therefore this commit records
which of the two kinds of AVIOContext is currently in use to use the
right way to close it.
Finally there was one instance (namely if initializing the child muxer
fails with no unrecognized options) where the AVIOContext was always
closed via the io_close callback. The above remark applies to this; it
has been fixed, too.
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
A string containing the segment's filename that the segment muxer
allocates got only freed in its write_trailer function. This implies
that it leaks if write_trailer is never called, e.g. if initializing
the child muxer fails. This commit fixes this by freeing the string
in the deinit function instead.
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The segment muxer has an option to output a file containing a list of
the segments written. The AVIOContext used for writing this file is
opened via the main AVFormatContext's io_open callback; seg_free()
meanwhile unconditionally closes this AVIOContext by calling
ff_format_io_close() with the child muxer (the one for the actual output
format) as AVFormatContext.
The problem hereby is that the child AVFormatContext need not exist,
even when the AVIOContext does. This leads to a segfault in
ff_format_io_close() when the child muxer's io_close callback is called.
Situations in which the AVFormatContext can be NULL range from an
invalid reference stream parameter to an unavailable/bogus/unsupported
output format to inability to allocate the AVFormatContext.
The solution is to simply close the AVIOContext with the AVFormatContext
that was used to open it: The main AVFormatContext.
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If the user has set none of the options specifying the segments'
durations, a default value of 2s is used by duplicating a "2" string and
using av_parse_time() on it. Yet duplicating the string was unchecked
and if the allocation failed, one would get a segfault in
av_parse_time().
This commit solves this by turning said option into an option of type
AV_OPT_TYPE_DURATION (which also uses av_parse_time() internally),
avoiding duplicating the string altogether.
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The code to free them is not in the segment muxer's deinit function,
but in its write_trailer function which means that these lists leak if
write_trailer isn't called after their allocation. This happens e.g. if
the given lists are invalid (e.g. consisting only of ',' (which delimit
entries)), so that parsing them fails and so does the muxer's init
function; write_trailer is then never called.
This has been fixed by moving the code to free them to the deinit
function.
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The segment muxer copies the user-provided AVCodecParameters to the
newly created child streams in its init function before initializing the
child muxer; and since commit 8e6478b723,
it does this again before calling avformat_write_header() if that is
called from seg_write_header(). The reason for this is complicated:
At that time writing the header was delayed, i.e. it was not triggered
by avformat_write_header() (unless the AVFMT_FLAG_AUTO_BSF was unset),
but instead by writing the very first packet. The rationale behind this
was to allow to run bitstream filters on the packets in the interleavement
queue in order to generate missing extradata from them before the muxer's
write_header function is actually called.
The segment muxer went even further: It initialized the child muxer and
ran the child muxer's check_bitstream functions on the packets in its
own muxing queue and stole any bitstream filters that got inserted. The
reason for this is that the segment muxer has an option to write the
header to a separate file and for this it is needed to write the child
muxer's header without delay, but with correct extradata. Unsetting
AVFMT_FLAG_AUTO_BSF for the child muxer accomplished the first goal and
stealing the bitstream filters the second; and in order for the child
muxer to actually use the updated extradata, the old AVCodecParameters
(set before avformat_init_output()) were overwritten with the new ones.
Updating the extradata proceeded as follows: The bitstream filter itself
simply updated the AVBSFContext's par_out when processing a packet, in
violation of the new BSF API (where par_out may only be set in the init
function); the muxing code then simply forwarded the updated extradata,
overwriting the par_in of the next BSF in the BSF chain with the fresh
par_out of the last one and the AVStream's par with the par_out of the
last BSF. This was an API violation, too, of course, but it made
remuxing ADTS AAC into mp4/matroska work.
But this no longer serves a useful purpose since the aac_adtstoasc BSF
was updated to propagate new extradata via packet side data in commit
f63c3516577d605e51cf16358cbdfa0bc97565d8; the next commit then removed
the code in mux.c passing new extradata along the filter chain. This
alone justifies removing the code for setting the AVCodecParameters a
second time.
But there is even another reason to do so: It is harmful. The ogg muxer
parses the extradata of Theora and Vorbis in its init function and keeps
pointers to parts of it. Said pointers become dangling when the
extradata is overwritten by the segment muxer, leading to
use-after-frees as has happened in ticket #8881 which this commit fixes.
Ticket #8517 is about another issue caused by this: Immediately after
having overwritten the old AVCodecParameters the segment muxer checks
whether the codec_tag is ok (the codec_tag is set generically when
initializing the child muxer based upon muxer-specific lists). The check
used is: If the child output format has such a list and if the codec tag
of the non-child stream does not match the codec id given the list of
codec tags and if there is a match for the codec id in the codec tag
list, then set the codec tag to zero (and not to the existing match),
otherwise set the codec tag of the child stream to the codec tag
of the corresponding stream of the main AVFormatContext (which is btw
redundant given that the child AVCodecParameters have just been
overwritten with the AVCodecParameters of the corresponding stream of
the main AVFormatContext).
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
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 96d70694ae was only for the case where
the file size was not known. It was not a maximum file size limit.
In 2912118898 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>
Also add and update some tests.
Change the semantic a little, because for filesytem paths
symlinks complicate things.
See the comments in the code for detail.
Fix trac tickets #8813 and 8814.
Writes color_primaries, color_trc and color_space to mxf
headers. ULs are from https://registry.smpte-ra.org/ site.
Signed-off-by: Harry Mallon <harry.mallon@codex.online>
Up until now, the TiVo demuxer parse an array of SEQ entries, yet it has
never ever made any use of them. In fact, parse_master, the function
parsing said table, only influenced the outside world in three ways: Via
an excessive amount of error message in case a certain parameter is not
what it expected; via an allocation (the aforementioned write-only
array); and by setting a certain parameter (ty->cur_chunk_pos), but that
parameter is always overwritten before it is used (it is overwritten
in get_chunk() on success and if get_chunk() fails, the error is
returned to the caller anyway). So remove the array and the function
used to parse it.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Alexander Strasser <eclipse7@gmx.net>
Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
Reviewed-by: Alexander Strasser <eclipse7@gmx.net>
Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
It has no bearing on structure. Determined by looking at the ASF
files from several Argonaut games:
- FX Fighter,
- Croc,
- Croc 2,
- The Emperor's New Groove, and
- Disney's Aladdin in Nasira's Revenge
The only versions that appear are 1.1, 1.2, and 2.1, and their
structure is identical.
Reviewed-by: Alexander Strasser <eclipse7@gmx.net>
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
Up until now, opening a section filter works as follows: A filter is
opened and (on success) attached to the MpegTSContext. Then a buffer for
said filter is allocated and upon success attached to the section
filter; on error, the filter is simply freed without removing it from
the MpegTSContext, leaving the latter in an inconsistent state. This
leads to use-after-frees lateron.
This commit fixes this by allocating the buffer first; the filter is
only opened if the buffer could be successfully allocated.
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
fix ticket: 8783
Because in single file by encryption mode, it cannot get the last one
block of the file, it need ff_format_io_close for get full file size,
then hlsenc can get the total size of the encryption content,
so write the content into temp file first, and get the temp file content
append the temp file content into append to single file, then hlsenc can
get the correct file/content size and offset.
Signed-off-by: Steven Liu <liuqi05@kuaishou.com>
It leads to an assert in ff_read_packet().
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reads color_primaries, color_trc and color_space from mxf
headers. ULs are from https://registry.smpte-ra.org/ site.
Signed-off-by: Harry Mallon <harry.mallon@codex.online>
This commit avoids allocating a DVDemuxContext when demuxing raw DV by
making it part of the demuxer's context. This also allows to remove
dv_read_close().
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
Fixes: 24457/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5760093644390400
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
flush_put_bits() already fills the bitstream with zeroes, so it is
unnecessary to align the bitstream before.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Also query time only once, not for every variant stream, otherwise variant
streams might get a slightly different initial program date time. And we can
set this unconditionally because HLS_PROGRAM_DATE_TIME flag is checked
elsewhere.
Signed-off-by: Marton Balint <cus@passwd.hu>
For non-PCM audio, a Smacker frame contains the size of the decoded
audio in the first four bytes of the audio packet data; for PCM data,
said information would be redundant and according to [1] this field does
not exist. Therefore this commit sets the duration and timestamps
properly for PCM audio.
[1]: https://wiki.multimedia.cx/index.php/Smacker#Audio_Track_Chunk
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Add .read_seek function to the smacker demuxer for the special case of
seeking to ts=0. This is useful because smacker – like bink, with a
similar implementation – was mostly used to encode clips in video
games, where random seeks are rare but looping media are common.
Signed-off-by: Timotej Lazar <timotej.lazar@araneo.si>
libsrt changed the:
SRTO_SMOOTHER -> SRTO_CONGESTION
SRTO_STRICTENC -> SRTO_ENFORCEDENCRYPTION
and removed the front of deprecated options (SRTO_SMOOTHER/SRTO_STRICTENC)
in the header, it's lead to build fail
fix#8760
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
Up until now, the Sega FILM muxer would first write all the packet data,
then shift the data (in the muxer's write_trailer function) by the amount
necessary to write the header at the front (which entails a seek to the
front), then seek back to the beginning and actually write the header.
This commit changes this: The dynamic buffer that is used to write the
sample table (containing information about each sample in the file) is
now used to write the complete header. This is possible because the size
of everything in the header except the sample table is known in advance.
Said buffer can then be used as one of the two temporary buffers used
for shifting which also reduces the amount one has to allocate for this.
Thereby the header will be written when shifting, so that the second
seek to the beginning is unnecessary.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, the Sega FILM muxer would store some information about
each packet in a linked list. When writing the trailer, the information
in said linked list would be used to write a table in the file header.
Each entry in said table is 16 bytes long, but each entry of the linked
list is 32 bytes long (assuming 64 bit pointer and no padding).
Therefore it makes sense to remove the linked list and write the array
entries directly into a dynamic buffer while writing the packet (this is
possible because the table entries don't depend on any information not
available when writing the packet (the offset is not relative to the
beginning of the file, but to the end of the table). This also
simplifies writing the array at the end (there is no need to traverse a
linked list).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Mostly using intermediate pointers for accesses (i.e. storing s->pb in a
variable pb and then using pb for writing instead of s->pb) to improve
readability. Furthermore, the opening brace '{' of a function has been
moved into a line of its own in instances where it wasn't before.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Also return proper error codes when it is absent: AVERROR(EINVAL)
instead of AVERROR_INVALIDDATA.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
When using the WebM DASH Manifest muxer, every stream of each adaptation
set has to contain a metadata entry containing the filename of the
source file. In case of live stream manifests, said filename has to
conform to a pattern of
<file_description>_<representation_id>.<extension>. These pieces are
used to create the other strings that are actually output. Up until now,
these other strings would be allocated, used once and then freed
directly after usage. This commit changes this: The function that
allocated and assembled these strings now returns pointers to the '_'
and '.' delimiters and so that the caller can easily pick substrings
from it without needing to copy the string.
Avoiding allocations also fixes a memleak: One of the allocated strings
would leak upon a subsequent allocation failure.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
In 1ec2b3de5a, the extradata size was affected when the raster was
signaled as flipped due to user-set option rather than via extradata.
This resulted in a wrong header size being written. Fixed.
The Matroska demuxer currently always opens a GetByteContext to read the
content of the projection's private data buffer; it does this even if
there is no private data buffer in which case opening the GetByteContext
will lead to a NULL + 0 which is undefined behaviour.
Furthermore, in this case the code relied both on the implicit checks
of the bytestream2 API as well as on the fact that it returns zero
if there is not enough data available.
Both of these issues have been addressed by not using the bytestream API
any more; instead the data is simply read directly by using AV_RB. This
is possible because the offsets are constants.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
When parsing MXF encountering some tags leads to allocations. And when
these tags were encountered repeatedly, this could lead to memleaks,
because the pointer to the old data got simply overwritten with a
pointer to the new data (or to NULL on allocation failure). This has
been fixed.
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The MXF demuxer uses an array of pointers to different structures of
metadata (all containing a common initial sequence containing a type
field to distinguish them) and some of these structures contain pointers
to separately allocated subelements. If an error happens while reading
and creating the tags, the semi-finished new tag is freed using the
function to free these tags. But this function doesn't free the already
allocated subelements, because the type has not been set yet. This commit
changes this.
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Said array contains pointers to other structs and both the designated
new element as well as other stuff contained in it (e.g. strings) leak
if the new element can't be added to the array.
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: signed integer overflow: 33986707200000000 + 9195561788997000192 cannot be represented in type 'long'
Fixes: 23790/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-6554232198266880
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Because the newpos variable is set value before use it.
The newpos variable declared at the head partition of crypto_seek.
Make the code clean.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
When there are potentially annotation (i.e. metadata) fields to write,
au_get_annotations() is called to produce a string with them. To do so,
it uses an AVBPrint which is finalized to create the string. This is
wasteful, because it always leads to an allocation even if the string
actually fits into the internal buffer of the AVBPrint. This commit
changes this by making au_get_annotations() modify an AVBPrint that
resides on the stack of the caller (i.e. of au_write_header()).
Furthermore, the AVBPrint is now checked for truncation; limiting
the allocations implicit in the AVBPrint allowed to offload the overflow
checks. Notice that these were not correct before: The size parameter of
avio_write() is an int, yet the string in the AVBPrint was allowed to
grow bigger than INT_MAX. And if the length of the string was so near
UINT_MAX that the length + 32 overflowed, the old code would write the
first eight bytes of the string and nothing more, leading to an invalid
file.
Finally, the special case in which the metadata dictionary of the
AVFormatContext is empty (in which case one still has to write eight
binary zeroes) is now no longer treated specially, because this case
no longer incurs any allocation.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This av_freep(&key) in conjunction with the fact that the loop condition
checks for key != NULL was equivalent to a av_freep(&key) + a break
immediately thereafter. But given that there is an av_freep(&key)
directly after the loop, the av_freep(&key) is unnecessary and the break
can also be added explicitly.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Some legacy applications such as AVI2MVE expect raw RGB bitmaps
to be stored bottom-up, whereas our RIFF BITMAPINFOHEADER assumes
they are always stored top-down and thus write a negative value
for height. This can prevent reading of these files.
Option flipped_raw_rgb added to AVI and Matroska muxers
which will write positive value for height when enabled.
Note that the user has to flip the bitmaps beforehand using other
means such as the vflip filter.
15d160cc0b increased the UDP socket receiving buffer size
(64K ->384K), but missed to update this comments.
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
No audio stream is created unconditionally and if none has been created,
no packet with stream_index 1 may be returned. This fixes an assert in
ff_read_packet() in libavformat/utils reported in ticket #8782.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Instead use ffio_read_size to read data into a buffer. Also check that
the desired size was actually successfully read and combine the check
with the check for reading the extradata.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Allocating two arrays with the same number of elements together
simplifies freeing them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
A Smacker file can contain up to seven audio tracks. Up until now,
the pts for the i. audio packet contained in a Smacker frame was
simply the end timestamp of the last i. audio packet contained in
an earlier Smacker frame.
The problem with this is that a Smacker stream need not contain data in
every Smacker frame and so the current i. audio packet present may come
from a different underlying stream than the last i. audio packet
contained in an earlier frame.
The sample hypnotix.smk* exhibits this. It has three audio tracks and
the first of the three has a longer first packet, so that the audio for
the first track is contained in only 235 packets contained in the first
235 Smacker frames; the end timestamp of this track is 166696 (about 7.56s
at a timebase of 1/22050); the other two audio tracks both have 253 packets
contained in the first 253 Smacker frames. Up until now, the 236th
packet of the second track being the first audio packet in the 236th
Smacker frame would get the end timestamp of the last first audio packet
from the last Smacker frame containing a first audio packet and said
last audio packet is the first audio packet from the 235th Smacker frame
from the first audio track, so that the timestamp is 166696. In contrast,
the 236th packet from the third track (whose packets contain the same number
of samples as the packets from the second track) has a timestamp of
156116 (because its timestamp is derived from the end timestamp of the
235th packet of the second audio track). In the end, the second track
ended up being 177360/22050 s = 8.044s long; in contrast, the third
track was 166780/22050 s = 7.56s long which also coincided with the
video.
This commit fixes this by not using timestamps from other tracks for
a packet's pts.
*: https://samples.ffmpeg.org/game-formats/smacker/wetlands/hypnotix.smk
Reviewed-by: Timotej Lazar <timotej.lazar@araneo.si>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The layout of a Smacker frame is as follows: For some frames, the
beginning of the frame contained a palette for the video stream; then
there are potentially several audio frames, followed by the data for the
video stream.
The Smacker demuxer used to read the palette, then cache every audio frame
into a buffer (that gets reallocated to the desired size every time a
frame is read into this buffer), then read and return the video frame
(together with the palette). The cached audio frames are then returned
by copying the data into freshly allocated buffers; if there are none
left, the next frame is read.
This commit changes this: At the beginning of a frame, the palette is
read and cached as now. But audio frames are no longer cached at all;
they are returned immediately. This gets rid of copying and also allows
to remove the code for the buffer-to-AVStream correspondence.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The first four bytes of smacker audio are supposed to contain the number
of samples, so treat audio frames smaller than that as invalid.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
When reading a new frame, the Smacker demuxer seeks to the next frame
position where it excepts the next frame; then it (potentially) reads
the palette, the audio packets associated with the frame and finally the
actual video frame. It is only at the end that the frame counter as well
as the position where the next frame is expected get updated.
This has a downside: If e.g. invalid data is encountered when reading
the palette, the demuxer returns immediately (with an error) and if the
caller calls av_read_frame again, the demuxer seeks to the position where
it already was, reads the very same palette data again and therefore will
return an error again. If the caller calls av_read_frame repeatedly
(say, until a packet is received or until EOF), this meight become an
infinite loop.
This could also happen if e.g. the size of one of the audio frames was
invalid or if the frame size was gigantic.
This commit changes this by skipping a frame if it turns out to be
invalid or an error happens otherwise. This ensures that EOF will be
returned eventually in the above scenario.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The Smacker demuxer buffers audio packets before it outputs them, but it
increments the counter of buffered packets prematurely: If allocating
the audio buffer fails, an error (most likely AVERROR(ENOMEM)) is returned.
If the caller decides to call av_read_frame() again, the next call will
take the codepath for returning already buffered audio packets and it
will fail (because the buffer that ought to be allocated isn't) without
decrementing the number of supposedly buffered audio packets (it doesn't
matter whether there would be enough memory available in subsequent calls).
Depending on the caller's behaviour this is potentially an infinite loop.
This commit fixes this by only incrementing the number of buffered audio
packets after having successfully read them and unconditionally reducing
said number when outputting one of them. It also changes the semantics
of the curstream variable: It is now the number of currently buffered
audio packets whereas it used to be the index of the last audio stream
to be read. (Index refers to the index in the array of buffers, not to
the stream index.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Don't need to do double check by the description of the API.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Saves initialization of an HEVCDecoderConfigurationRecord when
the data is already in ISOBMFF-format or if it is plainly invalid.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fix two cases of memleaks:
1. The leak of dv_demux
2. The leak of dv_fctx upon dv_demux allocate failure
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The code for demuxing DV audio predates the introduction of refcounted
packets and when the latter was added, changes to the former were
forgotten. This meant that when avpriv_dv_produce_packet initialized the
packet containing the AVBufferRef, the AVBufferRef as well as the
underlying AVBuffer leaked; the actual packet data didn't leak: They
were directly freed, but not via their AVBuffer's free function.
https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4671/dir1.tar.bz2
contains samples for this (enable_drefs needs to be enabled for them).
Moreover, errors in avpriv_dv_produce_packet were ignored; this has been
changed, too.
Furthermore, in the hypothetical scenario that the track has a palette,
this would leak, too, so reorder the code so that the palette code
appears after the DV audio code.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: signed integer overflow: 8 * 9223372036854774783 cannot be represented in type 'long'
Fixes: 23381/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-4818340509122560
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The segments / url can be modified by the io read when reloading
This may be an alternative or additional fix for Ticket8673
as a further alternative the reload stuff could be disabled during
probing
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Also switch to using a pointer to access stream side data instead of
copying the stream's AVPacketSideData.
Reviewed-by: Limin Wang <lance.lmwang@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
When doing streamed output, with e.g. +dash, if the mfra box ended
up being larger than the AVIOContext write buffer, the (unchecked)
seeking back to update the box size would silently fail and produce
an invalid mfra box.
This is similar to how other boxes are written in fragmented mode.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Nothing written in avformat_write_trailer() for the submuxers will be
output anyway because the AVIOContexts used for actual output have been
closed before the call. Writing the trailer of the subcontext has probably
only been done in order to free the memory allocated by the submuxer.
And this job has been taken over by the deinit functions.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: signed integer overflow: 1394614304 * 2 cannot be represented in type 'int'
Fixes: 23491/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5697377020411904
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Up until now, ff_avc_decode_sps would parse a SPS and return some
properties from it in a freshly allocated structure. Yet said structure
is very small and completely internal to libavformat, so there is no
reason to use the heap for it. This commit therefore changes the
function to return an int and to modify a caller-provided structure.
This will also allow ff_avc_decode_sps to return better error codes in
the future.
It also fixes a memleak in mxfenc: If a packet contained multiple SPS,
only the SPS structure belonging to the last SPS would be freed, the
other ones would leak when the pointer is overwritten to point to the
new SPS structure. Of course, without allocations there are no leaks.
This is Coverity issue #1445194.
Furthermore, the SPS structure has been renamed from
H264SequenceParameterSet to H264SPS in order to avoid overlong lines.
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
After parsing the end timestamp of a WebVTT cue block, the current code
skips everything after the start of the timestamp that is not a \t, ' '
or \n and treats what is next as the start of a WebVTT cue settings list.
Yet if there is no such list, but a single \r, this will skip a part of
the cue payload (namely everything until the first occurence of \t, ' '
or \n) and treat what has not been skipped as the beginning of the
WebVTT cue settings list that extends until the next \r or \n (or the
end).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Given that AV1 only has exactly one sequence header, it is unnecessary
to copy the content of said sequence header into an intermediate dynamic
buffer; instead the sequence header can be copied from where it is in
the input buffer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Fixes: signed integer overflow: 1 - -9223372036854775808 cannot be represented in type 'long'
Fixes: 23490/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5133490093031424
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Given that av_get_packet returns a blank packet on error, the only
difference to the current approach (that uses intermediate AVPackets on
the stack) is that st->attached_pic will be properly initialized on error
(i.e. the timestamps are AV_NOPTS_VALUE) whereas right now st->attached_pic
is only zeroed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Document that it also sets the size in case the desired side data is
absent (if the pointer has been supplied).
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If stream's bitrate is not specified:
- for static manifest: an average bitrate will be calculated and used,
- for dynamic manifest: first segment's bitrate will be calculated and used, as before,
for bandwidth setting in adaptation sets.
dash demuxer get the stream info from sub-stream, but missed side
data/disposition part, e,g, missed the DOVI side data when the
stream is Dolby Vision streams
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
hls demuxer get the stream info from sub-stream, but missed side
data/disposition part, e,g, missed the DOVI side data when the
stream is Dolby Vision streams.
Reviewed-by <liuqi05@kuaishou.com>
Signed-off-by: vacingfang <vacingfang@tencent.com>
This is a requirement of the AV1-ISOBMFF spec. Section 2.1.
General Requirements & Brands states:
* It SHALL have the av01 brand among the compatible brands array of the FileTypeBox
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
