It has never been done in b08569a239,
30b8f3e7dc.
After this change, this muxer does no longer use sizeof(AVPacket).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The documentation of said packet ("Every user has to ensure that
this packet is blank after using it") perfectly fits how we use said
packet in the generic muxing code. Better than the documentation of pkt.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Currently the interleave_packet functions use a packet for
a new packet to be interleaved (may be NULL if there is none) and
a packet for output; said packet is always a stack packet in
interleaved_write_packet(). But all the interleave_packet functions
in use first move the packet to the packet list and then check whether
a packet can be returned, i.e. the effective lifetime of the new packet
ends before the packet for output is touched.
So one can use one packet both for input and output by adding a new
parameter that indicates whether there is a packet to add to the packet
list; there is just one complication: In case the muxer is flushed,
there is no packet available. This can be solved by reusing one of
the packets from AVFormatInternal. They are currently unused when
flushing in av_interleaved_write_frame().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The earlier documentation claimed that av_interleaved_write_frame()
always orders by dts, which is not necessarily true when using muxers
with custom interleavement functions or the audio_preload option.
Furthermore, the documentation stated that libavformat takes ownership
of the reference of the provided packet (if it is refcounted) and that
the caller may not access the data through this reference after the
function returns. This suggests that the returned packet is not blank,
but instead still contains some set, but invalid fields, which implies
that it would be dangerous to unreference this packet again.
But this is not true: av_interleaved_write_frame()'s actual behaviour
is to always output blank packet (even on error). This commit documents
this fact so that callers know that they can directly reuse this packet.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The BSF API treats such packets as signalling EOF and therefore
such a packet might corrupt the BSF state. In such a case,
the guarantee that av_interleaved_write_frame() always frees
the packet is not upheld.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It claims to always zero-terminate its buffer like snprintf(),
yet it does it not on EOF. Because of this the mcc demuxer
used uninitialized values when reading an empty input file.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
ff_subtitles_queue_insert() does not require its events to be
zero-terminated as it has a parameter for the length.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The av_sscanf() will filter lines like "Scenarist_SCC V1.0" out.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, the scc demuxer not only read the line that it intends
to process, but also the next line, in order to be able to calculate
the duration of the current line. This approach leads to unnecessary
complexity and also to bugs: For the last line, the timing of the
next subtitle is not only logically indeterminate, but also
uninitialized and the same applies to the duration of the last packet
derived from it.* Worse yet, in case of e.g. an empty file, it is not
only the duration that is uninitialized, but the whole timing as well
as the line buffer itself.** The latter is used in av_strtok(), which
could lead to crashes. Furthermore, the current code always outputs
at least one packet, even for empty files.
This commit fixes all of this: It stops using two lines at a time;
instead only the current line is dealt with and in case there is
a packet after that, the duration of the last packet is fixed up
after having already parsed it; consequently the duration of the
last packet is left in its default state (meaning "unknown/up until
the next subtitle"). If no further line could be read, processing
is stopped; in particular, no packet is output for an empty file.
*: Due to stack reuse it seems to be zero quite often; for the same
reason Valgrind does not report any errors for a normal input file.
**: While ff_subtitles_read_line() claims to always zero-terminate
the buffer like snprintf(), it doesn't do so if it didn't read anything.
And even if it did, it would not necessarily help here: The current
code jumps over 12 bytes that it deems to have read even when it
hasn't.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Before adts_aac_resync would always bail out after probesize amount
of bytes had been progressed from the start of the input.
Now just query the current position when entering resync, and at most
advance probesize amount of data from that start position.
Fixes#9433
There can only be a maximum of 255 entries in a tfrf tag, so using
more makes no sense; moreover, several size computations can overflow
in this case. Fix this by limiting it to 255.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Do this by using the AVStream's priv_data for the buffer holding
the packet size data.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
If an array for the packet sizes could not be successfully reallocated
when writing a packet, the CAF muxer frees said array, but does not
reset the number of valid bytes. As a result, when the trailer is
written later, avio_write tries to read that many bytes from NULL,
which segfaults.
Fix this by not freeing the array in case of error; also, postpone
writing the packet data after having successfully (re)allocated the
array, so that even on allocation error the file can be correctly
finalized.
Also remove an unnecessary resetting of the number of size entries
used at the end.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
(As long as avio_write() only accepts an int, it makes no sense
to try to support sizes that don't fit into an int.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes: signed integer overflow: 9223372036854775360 + 536870912 cannot be represented in type 'long'
Fixes: 37940/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-6095637855207424
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Andreas Rheinhardt
Paul B Mahol
Derek Buitenhuis
Soft Works
Limin Wang
Jan Ekström
Michael Niedermayer