04d2540c added intreadwrite.h to avienc.c, although there was (and is)
no need to do so. The inclusion seems to be a mistake as this commit
added a AV_WL32 to avidec.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
bswap.h was included since 7b114c09, yet since 3788a3c0 no explicit use
of anything from bswap.h has been made, so remove this header.
(Only AV_RL32 is used and while this might imply swapping on
big-endian systems, it is contained in libavutil/intreadwrite.h.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
libavutil/parseutils.h has been included in 22bbd6e8 for av_parse_time()
and the header has not been removed when said function was replaced by
ff_parse_creation_time_metadata() in ea1bf08a.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Prevents memleaks if the trailer is never written.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fix#7620
In the case tee muxer with both "bsf" and "use_fifo" parameters
will trigger this bug. Tee muxer will first steal parameters (like "f",
"select"...) and then "use_fifo" will try reading out remaining options
and pass them to fifo as option "format_options".
Current code miss the part of stealing "bsf" options.
In order to fix a potential memleak upon failure, 0b8956b2 made sure that
a buffer given by a pointer was freed upon error. But this pointer was
only initialized upon use and in several cases (Clang gives no fewer
than 13 -Wsometimes-uninitialized warnings) this meant that an
uninitialized pointer was used to free a buffer. So initialize the
pointer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Prevents memleaks in situations where the trailer isn't written, e.g.
because of errors during writing the header.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Extradata is supposed to be padded with AV_INPUT_BUFFER_PADDING_SIZE bytes,
yet the VobSub demuxer used av_strdup for the allocation of extradata.
This has been changed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Contains renaming of variables (e.g. mkv_write_cues() contained
variables called tracknum that actually contain the index of a track in
s->streams and not the track number (which can differ in case an
explicit dash track number is set)).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
mkv_start_new_cluster() actually didn't start a new cluster, but ended
the old one instead and emitted a debug message that it had started a
new cluster. This has been changed: The debug message has been moved to
the place that really starts a new cluster and the function has been
renamed to mkv_end_cluster().
Furthermore, without this debug message the function can be used for
flushing.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
The Matroska muxer groups index entries with the same pts together in
order to save a few bytes. Because of Matroska's variable-length length
fields, mkv_write_cues() does this by first finding out how many index
entries will be grouped together before actually writing them.
Currently, it is asserted at both of these stages that the stream index
of the list of designated index entries is valid. But the second assert
is redundant, because the very same index entries have already been
checked.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
The Matroska muxer up until now leaked memory in two scenarios:
1. If an error happened during writing the trailer, as
mkv_write_trailer() returned early without cleaning up.
2. If mkv_write_header() indicated success despite an error in the
underlying AVIOContext. In this case avformat_write_header() returned
the IO error and according to the API the caller is not allowed to call
av_write_trailer(), so that no cleanup happened for the allocations made
in mkv_write_header().
This has been fixed by using a dedicated deinit function.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
If the trailer is never writen, there could be buffered pages that would leak.
Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Despite the doxy stating that it's called when the muxer is destroyed,
this was not true in practice. It's only called by av_write_trailer()
and on init() failure.
An AVFormatContext may be closed without writing the trailer if errors
ocurred while muxing packets, so in order to prevent memory leaks, it
should effectively be called when freeing the muxer.
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: signed integer overflow: -3 - 9223372036854775807 cannot be represented in type 'long'
Fixes: 17828/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5645915116797952
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avformat_free_context() expects AVFormatContext->internal to not be NULL.
Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
If there is an error in mpeg_mux_init() (the write_header function of
the various MPEG-PS muxers), two things might happen:
1. Several fifos might leak. Instead of freeing them, the goto fail part
of the functions freed the private data of the AVStreams instead,
although this will be freed later in free_stream() anyway.
2. And if the function is exited via goto fail, it automatically
returned AVERROR(ENOMEM), although this is also used when the error is
not a memory allocation failure.
Both of these issues happened in ticket #8284 and have been fixed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The pointer fp after the call to chromaprint_get_raw_fingerpoint() points to an array
of uint32_t whereas the current code assumed just a char stream. Thus when writing the
raw fingerprint, the output would be truncated by a factor of 4.
For reference the declaration of the function from chromaprint.h is:
int chromaprint_get_raw_fingerprint(ChromaprintContext *ctx, uint32_t **fingerprint, int *size);
