The auxiliary data length field is not reliable,
and incorrect overread errors could be returned
for valid, real-world bitstreams.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

MSYS, as per cygwin, by default uses a custom posix abstraction
in the form of a "msys2.dll". Programs build that way are harder to
distribute and use.

MSYS2 provides alternate launcher scripts that provide a MINGW
environment nearly out of box.

This function returns the encoded data of a frame, one slice at a time
directly when that slice is encoded, instead of waiting for the full
frame to be done. However this field has a debatable usefulness, since
it looks like it is just a convoluted way to get data at lowest
possible latency, or a somewhat hacky way to store h263 in RFC-2190
rtp encapsulation.

Moreover when multi-threading is enabled (which is by default) the order
of returned slices is not deterministic at all, making the use of this
function not reliable at all (or at the very least, more complicated
than it should be).

So, for the reasons stated above, and being used by only a single encoder
family (mpegvideo), this field is deemed unnecessary, overcomplicated,
and not really belonging to libavcodec. Libavformat features a complete
implementation of RFC-2190, for any other case.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Currently, multiple slices with just one thread produce corrupted
output.

Additionally, enable slice structured mode for h263(+)

Bug-Id: 912
CC: libav-stabl@libav.org

They do not work and produce corrupted output.

CC: libav-stable@libav.org

This feature allows making associations between audio tracks
that apple players recognize.  E.g. when an ac3 track has a
tref that points to an aac track, devices that don't support
ac3 will automatically fall back to the aac track.

Apple used to *guess* these associations, but new products
(AppleTV 4) no longer guess and this association can only
be made explicitly now using the "fall" tref.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

This side data type is meant to be added to AVStream side data.
A fallback track indicates an alternate track to use when the
current track can not be decoded for some reason.  e.g. no
decoder available for codec.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Also, extend the documentation about setting timestamps.

CC: libav-stable@libav.org

This mimics what the code does internally for default order values.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

FFv1 uses two types of coders, golomb and range with two different
tables. This is exposed this in a rather convoluted way, for example
mentioning to set coder type 1 while initializing the variable 'ac' to 2,
because encoder does not use range coder with default table.

Appropriate internal coder type values have been added and used in any
check rather than using raw numbers.

Initialization of avctx.coder_type in ffv1dec is removed because this
field is encoder only. An unneeded validation check in the encoder
is dropped too.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

It is used as size argument of ff_canopus_parse_info_tag, which uses it
as size argument to bytestream2_init, which only supports sizes up to
INT_MAX.
Changing it's type to unsigned simplifies the check.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

Having both is not valid and can cause a NULL pointer dereference of
frame->data[1] later.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

The XTEA algorithm operates on 32 bit numbers, not on byte sequences.
The XTEA implementation in libavutil is written assuming big endian
numbers, while the rtmpe signature encryption assumes little endian.

This fixes rtmpe communication with rtmpe servers that use signature
type 8 (XTEA), e.g. crunchyroll.
Signed-off-by: Martin Storsjö <martin@martin.st>

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

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

Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

A too small buffer will cause segfaults somewhere below
decompress_texture_thread.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

If it is too small av_image_copy_plane segfaults.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

Some entries might be either empty or contain types we do not parse
(eg. 'url '). In both cases, if an 'alis' is not the first entry,
external references are not loaded, so make sure that the array starts
with an 'alis' dref.

Rather than reading the alternate absolute path version from dref
type 18, make sure that 0s are considered as '/'. These values are
sometimes present in the full path, and are mistakenly interpreted as
line terminators othewise.

With the correct handling of this dref type, parsing type 18 is not
needed any more.

Signed-off-by: Paul B Mahol <onemda@gmail.com>

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

By writing a zero-sized packet, the caller can communicate the
start_dts/start_cts for the stream without actually writing
the first packet.

This allows doing random-access writing of fragments when the
start dts of the stream isn't zero, so that the edit list in the moov
is written based on timestamps from the nominal start time signaled
via the zero-sized packet, while the first proper packet written
corresponds to a later fragment.

To avoid potential unexpected behaviour, empty packets only set
start_dts if the frag_discont flag is set.
Signed-off-by: Martin Storsjö <martin@martin.st>

This tests the case where the muxer correctly guesses that a stream
starts at pts=0.
Signed-off-by: Martin Storsjö <martin@martin.st>

This allows producing fragments discontinously where the video
stream has b-frames (but starts at pts=0), but doesn't work for the
cases with audio with preroll.
Signed-off-by: Martin Storsjö <martin@martin.st>

Contrary to the normal fate tests that run via avconv, this tests
nontrivial call sequences that are only doable via the API
(mainly for different corner cases when using the muxer for
segmenting).

The test muxes fake packet data (with extradata that looks
enough like proper data to make the file be viewable with e.g.
boxdumper) and checks the hash of the produced files. The test also
verifies that fragments produced via different call sequences remain
identical (to avoid e.g. updating the output hashes and suddenly
having fragments that used to be identical suddenly diverging), for
fragments written with frag_discont and/or delay_moov.
Signed-off-by: Martin Storsjö <martin@martin.st>