Up until now, the VC-1 decoders allocated an AVFrame for usage with
sprites during vc1_decode_init(); yet said AVFrame can be freed if
(re)initializing the context (which happens ordinarily during decoding)
fails. The AVFrame does not get allocated again lateron in this case,
leading to segfaults.
Fix this by moving the allocation of said frame immediately before it is
used (this also means that said frame won't be allocated at all any more
in case of a regular (i.e. non-image) stream).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It automatically records the current length of the string,
whereas the current code contains lots of instances of
snprintf(buf + strlen(buf), buf_size - strlen(buf), ...).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If the numerical constants for colorspace, transfer characteristics
and color primaries coincide, the current code presumes the
corresponding names to be identical and prints only one of them obtained
via av_get_colorspace_name(). There are two issues with this: The first
is that the underlying assumption is wrong: The names only coincide in
the 0-7 range, they differ for more recent additions. The second is that
av_get_colorspace_name() is outdated itself; it has not been updated
with the names of the newly defined colorspaces.
Fix both of this by using the names from
av_color_(space|primaries|transfer)_name() and comparing them via
strcmp; don't use av_get_colorspace_name() at all.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Our "get name" functions can return NULL for invalid/unknown
arguments. So check for this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
When the trailer is never written (or when a stream switches from
non-animation mode to animation mode mid-stream), a cached packet
(if existing) would leak. Fix this by adding a deinit function.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The WebP muxer sometimes caches a packet it receives to write it later;
yet if a cached packet is too small (so small as to be invalid),
it is cached, but not written and not unreferenced. Such a packet leaks,
either by being overwritten by the next packet or because it is never
unreferenced at all.
Fix this by not caching unusable packets at all; and error out on
invalid packets.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Replace it in ipmovie_read_header() by AVFormatInternal.parse_pkt
which is unused when reading the header.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
They will be discarded anyway because this can only happen
for invalid data. This already implies that the pkt won't be used
at all when parsing the very first chunk when reading the header,
so one can use NULL as argument and remove the av_packet_unref()
on error.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
When one of these errors happens during ipmovie_read_packet(),
an error is returned and the packet is cleaned up generically.
And since 712d3ac539 the same happens
in ipmovie_read_header().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Replace it by using AVFormatInternal.parse_pkt which is otherwise unused
when reading a header.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Before 8d78e90a6b the Matroska demuxer
used stack packets to hold temporary packets; now it uses a temporary
packet allocated by the Matroska demuxer. Yet because it used stack
packets the code has always properly reset the packet on error, while
on success these temporary packets were put into a packet list via
avpriv_packet_list_put(), which already resets the source packet.
This means that this code is compatible with just reusing
AVFormatInternal.parse_pkt (which is unused while one is in the
demuxer's read_packet() function). Compared to before 8d78e90a6
this no longer wastes one initialization per AVPacket read
(the resetting of the stack packet performed by av_packet_move_ref()
in avpriv_packet_list_put() was for naught).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Originally added in 12f996edfa
behind #if 0; aebb56e184 then
removed the #if and replaced it by using av_dlog. Then commit
1a3eb042c7 replaced this with av_log
at trace level. Yet the code block always stayed within { }
at an increased level of indentation.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The SVQ3 decoder modifies the input bitstream at two places.
One of them is only reached when the file is watermarked.
Therefore commit 2264c11081
made a copy of all the frame data in this case.
But there is a second possibility for modifying the frame and
therefore Libav commit 1098f5c049
made the decoder always copy the data. This of course makes
the additional copy for watermarked frames redundant, but it hasn't
been removed. This commit does so.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It takes care of zeroing padding (which has been forgotten here).
Also rename the size variable to indicate that this is not the size
of the current slice.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This makes av_read_frame() return packets with proper timestamps.
As a result, seeking now works in combination with streamcopy.
A FATE-test for this has been added.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Currently, ff_read_packet() sometimes forwards the return value of
AVInputFormat.read_packet() (which should be zero on success, but isn't
for all demuxers) and sometimes it overwrites this with zero.
Furthermore, it uses two variables, one for the read_packet return value
and one for other errors, which is a bit confusing; it is also
unnecessary given that the documentation explicitly states that
ff_read_packet() never returns positive values. Returning a positive
value would lead to leaks with some callers (namely asfrtp_parse_packet
and estimate_timings_from_pts). So always return zero in case of
success.
(This behaviour stems from a time before av_read_packet sanitized
the return value of read_packet at all: It was added in commit
626004690c and was unnecessary since
88b00723906f68b7563214c30333e48888dddf78.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Because the properties of frames returned from ff_get/reget_buffer
are not reset at all, lots of returned frames had palette_has_changed
wrongly set to 1. This has been changed, too.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This field needs to be replaced altogether, not just its type changed.
This will be done in a separate change.
Signed-off-by: James Almer <jamrial@gmail.com>
The test sample has to have no file extension, otherwise probing
happens to work, based off file extension alone, and we want to
test the actual probing function.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
When extended atom size support was added to probing in
fec4a2d232, the buffer
size check was backwards, but probing continued to work
because there was no minimum size check yet, so despite
size being 1 on these atoms, and failing to read the 64-bit
size, the tag was still correctly read.
When 0b78016b2d introduced a
minimum size check, this exposed the bug, and broke probing
any files with extended atom sizes, such as entirely valid
large files that start whith mdat atoms.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Commit 6973df1122 added support
for music tracks by outputting its two containing tracks
together in one packet. But the actual data is not contiguous
in the file and therefore one can't simply use av_get_packet()
(which has been used before) for it. Therefore the packet was
now allocated via av_new_packet() and read via avio_read();
and this is also for non-music files.
This causes problems because one can now longer rely on things
done automatically by av_get_packet(): It automatically freed
the packet in case of errors; this lead to memleaks in several
FATE-tests covering this demuxer. Furthermore, in case the data
read is less than the data desired, the returned packet was not
zero-allocated (the packet's padding was uninitialized);
for music files the actual data could even be uninitialized.
The former problems are fixed by using av_get_packet() for
non-music files; the latter problem is handled by erroring out
unless both tracks could be fully read.
Reviewed-by: Zane van Iperen <zane@zanevaniperen.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Always leaving said packet in a blank state after having used it
allows to avoid having to reset it before one uses it; and it also
allows to use it in more places than just in parse_packet() here.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
When flushing, the parser receives a dummy buffer with padding
that lives on the stack of av_parser_parse2(). Certain parsers
(e.g. Dolby E) only analyze the input, but don't repack it. When
flushing, such parsers return a pointer to the stack buffer and
a size of 0. And this is also what av_parser_parse2() returns.
Fix this by always resetting poutbuf in case poutbuf_size is zero.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Added in dc51a72ba4, yet even back then
the check was always true as the AVCodecContext has already been memset
to zero before that.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This is how it is supposed to happen, yet when using frame threading,
the codec's init function has been called before preinit. This can lead
to crashes when e.g. using unsupported lowres values for decoders
together with frame threading.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
These fields can't be set via AVOptions, ergo one can check them before
having allocated anything.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
