CC: libav-stable@libav.org
Bug-Id: CID 703624

Bug-Id: CID 1254668

CC: libav-stable@libav.org
Bug-Id: CID 747734

This is the order that the caller uses in the rest of the file. The
same operation is applied to both parameters, so this change is only
done for consistency, it doesn't change the actual behaviour.

Bug-Id: CID 732285 / CID 732286

CC: libav-stable@libav.org
Bug-Id: CID 717844

CC: libav-stable@libav.org
Bug-Id: CID 1257815

CC: libav-stable@libav.org

And break flow of execution rather than exiting the function.

CC: libav-stable@libav.org
Bug-Id: CID 732186

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

CC: libav-stable@libav.org
Bug-Id: CID 703706

And make sure the nb_side_data field is reset as well.

Based on an initial patch from wm4 <nfxjfg@googlemail.com>.

CC: libav-stable@libav.org

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Additional improvements and fixes by Michael Niedermayer <michaelni@gmx.at>.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

The pts and the corresponding duration is written in sidx
atoms, thus make sure these match up correctly.
Signed-off-by: Martin Storsjö <martin@martin.st>

Since this structurally is quite different from normal RTP
(multiple streams are muxed into one single mpegts stream,
which is packetized into one single RTP session), it is kept
as a separate muxer.

Since this structurally also behaves differently than normal
RTP, all of the other muxers that do chained RTP muxing
(rtsp, sap, mp4) would need to be updated similarly to handle
this - in particular, creating one single rtp_mpegts muxer
for the whole presentation instead of one rtp muxer per stream.
Signed-off-by: Martin Storsjö <martin@martin.st>

The packetizer only supports splitting at GOB headers - if
such aren't available frequently enough, it splits at any
random byte offset (not at a macroblock boundary either, which
would be allowed by the spec) and sends a payload header pretend
that it starts with a GOB header.

As long as a receiver doesn't try to handle such cases cleverly
but just drops broken frames, this shouldn't matter too much
in practice.
Signed-off-by: Martin Storsjö <martin@martin.st>

Instead explicitly jump to the default case in the cases where
it is wanted, and avoid fallthrough between different codecs,
which could easily introduce bugs if people editing the code
aren't careful.
Signed-off-by: Martin Storsjö <martin@martin.st>

ff_mpv_common_init sets s->context_initialized.

This fixes decoding of h261 in the cases where the demuxer
hasn't already set the frame size.

CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

This avoids trying to do sliced encoding, even if a slice/packet
size is requested (via the -ps option or the rtp_payload_size
field), since the encoder currently doesn't support it (or at least
our decoder can't decode it, even if the h261_encode_gob_header
function is hooked up to be called from the slicing part in
mpegvideo_enc.c).
Signed-off-by: Martin Storsjö <martin@martin.st>

If we throw away the buffered incomplete frame, make sure to also
throw away the buffered bits of an incomplete byte at the same
time.

CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

In particular, when packetizing mpegts into rtp, the input packet
timestamp may come from more than one stream, which could cause
multiple packets be written with the same timestamp.
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

This is the same adjustment that the mp4 muxer does to the start
timestamp of fragments, since the timestamp of a sample in an mp4
file is implicit from the sum of earlier sample durations.

This avoids gaps in the timeline (which can stop dash.js from
playing it back), and makes sure the timestamp on the segmenter
level matches what the mp4 muxer actually writes into the segments.

This is only an issue if the AVPacket duration of the last
packet of a segment doesn't point to the actual start timestamp
of the next packet (the first in the next segment).
Signed-off-by: Martin Storsjö <martin@martin.st>

Write a new start time if the duration of the previous segment
didn't match the start of the next one. Check that segments
actually are continuous before writing a repeat count.

This makes sure timestamps deduced from the timeline actually
match the real start timestamp as written in filenames (if
using a template containing $Time$).
Signed-off-by: Martin Storsjö <martin@martin.st>

Since 3cec81f4, a zero-length metadata value would try to
allocate 2*0 bytes, where av_malloc() returns NULL.

Always add one to the allocated length, to allow space for
a null terminator in the zero-length case.

Incidentally, this fixes fate-alac on RVCT 4.0, where a compiler
bug seems to mess up the mov muxer to the point that it writes
the wrong sort of metadata. Previously this bug was undetected,
but since 3cec81f4 such mov files started returning
AVERROR(ENOMEM) in the mov demuxer.
Signed-off-by: Martin Storsjö <martin@martin.st>

Only one instance affected and solved as other occurences.

Also use the same type for add_entry and check_size.

Bug-Id: CID 700699
CC: libav-stable@libav.org
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Signed-off-by: Vittorio Giovara <vittorio.giovarao@gmail.com>

Prevent an uninitialized data access.

CC: libav-stable@libav.org
Bug-Id: CID 703824 / CID 703825
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

In matroska_read_seek(), |tracks| is assigned at the begining of the
function. However, functions like matroska_parse_cues() could reallocate
the tracks and invalidate |tracks|.

This assigns |tracks| only before using it, so that it will not get
invalidated elsewhere.

Bug-Id: chromium/427266