Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: James Almer <jamrial@gmail.com>

Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: James Almer <jamrial@gmail.com>

Decoding can be handled directly in the output frame.

Also ensure flushing cleans the reference frame in all cases.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: James Almer <jamrial@gmail.com>

For FLAC, Speex, Opus and VP8 the Ogg muxer allocates two buffers
for building the headers: The first for extradata in an Ogg-specific
format and the second contains a Vorbiscomment. These buffers are
reachable via pointers in the corresponding AVStream's priv_data.

If an error happens during building the headers, the AVStream's
priv_data would be freed. This is pointless in general as it would be
freed generically anyway, but here it is actively harmful: If the second
of the aforementioned allocations fails, the first buffer would leak
upon freeing priv_data.

This commit stops freeing priv_data manually, which allows the muxer to
properly clean up in the deinit function.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

avformat_find_stream_info() may decode some frames to get stream
information. And when it does this for subtitles, the decoded subtitles
leak.

(Decoding subtitles was added in b1511e00
for PGS subtitles. When PGS subtitles originate from a container that
exports every segment as a packet of its own, no output will be
generated when decoding a packet, because not enough input is available.
Yet when used with PGS subtitles in the Matroska form a single packet
contains enough data to generate output. Yet said output is not freed,
hence this leak.)
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

In this example, the difference in length between the shortest and
longest string is three, so that not using pointers to strings saves
space even on 32bit systems.

Moreover, there is no need to use a sentinel here; it can be replaced
with FF_ARRAY_ELEMS.
Reviewed-by: Ross Nicholson <phunkyfish@gmail.com>
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

Fixes Coverity ID 1462307.
Reviewed-by: Marton Balint <cus@passwd.hu>
Reviewed-by: Ross Nicholson <phunkyfish@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Signed-off-by: Josh de Kock <josh@itanimul.li>

Signed-off-by: Josh de Kock <josh@itanimul.li>

Signed-off-by: Josh de Kock <josh@itanimul.li>

Signed-off-by: Josh de Kock <josh@itanimul.li>

Signed-off-by: Josh de Kock <josh@itanimul.li>

Fix an occasional crash for hevc decoder in ARM 32 platform, the
root cause is the memory over read(read cross the memory boundary)
in SAO NENO functions ff_hevc_sao_band_filter_neon_8 and
ff_hevc_sao_edge_filter_neon_8.

After this fix, the crash disapper in the massive Android phone
test.
Signed-off-by: qoroliang <qoroliang@tencent.com>

Protocol options like buffer_size need to be passed to the
underlying transport implementation for udp multicasts as well.
Signed-off-by: Marton Balint <cus@passwd.hu>

The x18 is a reserved platform register on Darwin and Windows.

x8/w8 seems to be unused in this function though (and same about
x10 and x14), so there's really no reason to use x18 here - just change
the uses of x18/w18 into x8/w8 instead without any further rewrites.
Signed-off-by: Martin Storsjö <martin@martin.st>

It's needed to assemble complete frames.
Signed-off-by: James Almer <jamrial@gmail.com>

The context structure of the truehd_core bsf had a pointer to a const
AVClass as its first member; yet this bsf does not have any AVClass
associated with it, so that this pointer is always NULL. So remove it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

Fixes: signed integer overflow: 40550400 * 128 cannot be represented in type 'int'
Fixes: 20331/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RV40_fuzzer-5676685725007872

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Marton Balint <cus@passwd.hu>

Currently Musepack allocates an array that needs to be freed later in
the demuxer's read_close-function; it is the sole reason for said
function's existence. But it is unnecessary, because one can store this
array in the stream's priv_data pointer, so that it will be freed
generically.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

Chapter titles are added to the chapter's metadata since 6cb6e159,
yet since 012867f0 (the predecessor of) avpriv_new_chapter() already
adds the title to the chapter's metadata. So setting it again in
matroskadec.c is redundant and expensive.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

Moreover, putting the Cues in front of the Clusters by reserving space
in advance is also tested.

The new capability of using ffprobe during a remux/transcode test are
used here for information about the chapters.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

This is primarily intended to test that muxers correctly write chapters
or metadata; but given that it does this by having our demuxers read the
generated files, it also tests demuxers. And of course it may prove
useful for encoders, too.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

Up until now, they were appended to the FATE_EXTERN-$(CONFIG_FFMPEG)
variable and were therefore activated when ffmpeg was enabled regardless
of whether ffprobe was enabled.

Also the same happened with FATE_SAMPLES_FASTSTART, although the
corresponding test (mov-faststart-4gb-overflow) only requires external
samples.

Furthermore, remove the unused FATE_FULL variable (FATE_EXTERN_FFPROBE has
taken its place).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

Signed-off-by: Peter Ross <pross@xvid.org>
Reviewed-by: Vittorio Giovara <vittorio.giovara@gmail.com>

It is a small buffer of a known, fixed size and so it should simply be
put into the muxer's context.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

An AVStream's codecpar is supposed to be filled by the caller before
avformat_write_header(); if the CodecParameters change, the caller
should signal this via packet side data, but not touch the AVStream's
codecpar.

The FLAC muxer checks for packet side data containing updated extradata,
yet if nothing has arrived by the time the trailer is written, the
already written extradata is overwritten by the very same extradata
again, unless the output is unseekable, in which case a warning that the
FLAC header can't be rewritten is emitted.

This commit changes this by only trying to rewrite the extradata if a
new streaminfo arrived via packet side data. Only then is a warning
emitted in case the output is unseekable.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

When no packet could be output, the interleavement functions
nevertheless initialized the packet destined for output (with the
exception of the data and size fields, making the initialization
pointless), although it will not be used at all. So remove the
initializations.
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

write_packet() currently saves the original timestamps of the packet it
got and restores them in case writing fails. This is unnecessary as we
are no longer working directly with the user-supplied AVPacket here; and
it is also pointless because the timestamps may already have been
altered before write_packet().

So remove this and add a general comment to the function that timestamps
may be modified; also remove a long outdated comment about side data.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

The documentation of av_write_frame() explicitly states that the function
doesn't take ownership of the packets sent to it; while av_write_frame()
does not directly unreference the packets after having written them, it
nevertheless modifies the packet in various ways:
1. The timestamps might be modified either by prepare_input_packet() or
compute_muxer_pkt_fields().
2. If a bitstream filter gets applied, it takes ownership of the
reference and the side-data in the packet sent to it.
In case of do_packet_auto_bsf(), the end result is that the returned packet
contains the output of the last bsf in the chain. If an error happens,
a blank packet will be returned; a packet may also simply not lead to
any output (vp9_superframe).
This also implies that side data needs to be really copied and can't be
shared with the input packet.
The method choosen here minimizes copying of data: When the input isn't
refcounted and no bitstream filter is applied, the packet's data will
not be copied.

Notice that packets that contain uncoded frames are exempt from this
because these packets are not owned by and returned to the user. This
also moves unreferencing the packets containing uncoded frames to
av_write_frame() in the noninterleaved codepath; in the interleaved
codepath, these packets are already freed in av_interleaved_write_frame(),
so that unreferencing the packets in write_uncoded_frame_internal() is
no longer needed. It has been removed.
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

Now that ff_interleave_add_packet() always returns blank packets, the
input packet to ff_interleave_packet_per_dts() will always be blank on
return as well (if supplied) and the same goes for interleave_packet()
in mux.c. Document these facts and remove the redundant resetting that
happened in av_interleaved_write_frame().

The last reference to the (long removed) destruct field that AVPackets
once had has been removed as well when updating the documentation of
ff_interleave_packet_per_dts().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>