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 712d3ac539f30239b764d8621829dc9dc913da61 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 8d78e90a6ba96646f7f25aff6ca3e12e71cec164 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 12f996edfab67b65af0ff1ee829f9eeabb025b0f
behind #if 0; aebb56e1844d61965c97e95534c3ae0da69df028 then
removed the #if and replaced it by using av_dlog. Then commit
1a3eb042c704dea190c644def5b32c9cee8832b8 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>
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
626004690c23c981f67228ea325dde3f35193988 and was unnecessary since
88b00723906f68b7563214c30333e48888dddf78.)
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>
When extended atom size support was added to probing in
fec4a2d232d7ebf6d1084fb568d4d84844f25abc, 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 0b78016b2d7c36b32d07669c0c86bc4b4225ec98 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 6973df112275c8ea4af0bf3cb1338baecc1d06b3 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>
Fixes: signed integer overflow: 9223372036854775807 + 536870912 cannot be represented in type 'long'
Fixes: 31678/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-5614204619980800
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
And forward it to the underlying UDP protocol.
Fixes ticket #7517.
Signed-off-by: Jiangjie Gao <gaojiangjie@live.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
Add the "http_proxy" option and its handling to the "tls" protocol,
pass the option from the "https" protocol.
The "https" protocol already defines the "http_proxy" command line
option, like the "http" protocol does. The "http" protocol properly
honors that command line option in addition to the environment
variable. The "https" protocol doesn't, because the proxy is
evaluated in the underlying "tls" protocol, which doesn't have this
option, and thus only handles the environment variable, which it
has access to.
Fixes#7223.
Signed-off-by: Moritz Barsnick <barsnick@gmx.net>
Signed-off-by: Marton Balint <cus@passwd.hu>
These files are technically a series of planar mono tracks.
If the "music" flag is set, merge the packets from the two
mono tracks, essentially replicating:
[0🅰️0][0🅰️1]join=inputs=2:channel_layout=stereo[a]
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
These are auxiliary side-data functions, so they should have been
switched to size_t in d79e0fe65c51491f9bf8a470bbe36fb09f3e1280,
but this has been forgotten.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
64 bits are needed in order to retain the uid values of Matroska
chapters; the type is kept signed because the semantics of NUT chapters
depend upon whether the id is > 0 or < 0.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until now, there has been no check that each chapter has a unique id;
there was only a check for whether a chapter id is zero (this happens
often when the chapters originated from a format that lacks the concept
of chapter id and simply counts from zero) which is invalid in Matroska.
In this case the chapter ids are offset by 1 to make them nonnegative.
Yet offsetting won't fix duplicate ids, therefore this is changed to
simply create new chapter uids when the input chapter uids don't conform
to the requirements of Matroska (in which case it can be presumed that
they did not originate from Matroska, so that we don't need to bother
to preserve them).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The test program for the FIFO muxer allocates a buffer without padding
and wraps it into a packet via av_packet_from_data(). This is an API
violation. Furthermore, said buffer leaks in case av_packet_from_data()
fails. Fix both of these issues by using av_new_packet() instead.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Also factor allocating and freeing the packet out.
Fixes Coverity issues #1473722 and #1473723; it is a regression
since 4b386b2059806ca7ee7f991d2c8b735410693e8c.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It was introduced in d3d9b1fc8e2dfc8b4d66c9916ab7221062ff4660;
Fixes Coverity issue #733800.
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If one of the two results of a ternary conditional is a pointer to void,
the type of the whole conditional operator is a pointer to void, even
when the other possible result is not a pointer to void. This loophole
in the type system has allowed mxf_read_local_tags to have a pointer of
type pointer to MXFMetadataSet that actually points to an MXFContext.
Reviewed-by: Tomas Härdin <tjoppen@acc.umu.se>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
