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>

In most other cases when writing fragmented mp4 files, the output
IO context is flushed after each fragment. Also flush it after
writing the initial moov, to have it behave in the same way.
Signed-off-by: Martin Storsjö <martin@martin.st>

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

(cherry picked from ffmpeg commit fdb93996)
Signed-off-by: Anton Khirnov <anton@khirnov.net>

(cherry picked from ffmpeg commit 353cf95f)
Signed-off-by: Anton Khirnov <anton@khirnov.net>

(cherry picked from ffmpeg commit a46a23d3)
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
(cherry picked from ffmpeg commit 227b4458)
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Useful for dealing with constant frame-rate video.

(cherry picked from ffmpeg commit 722762f7)
Signed-off-by: Anton Khirnov <anton@khirnov.net>

(cherry picked from ffmpeg commit 7cd5fa35)
Signed-off-by: Anton Khirnov <anton@khirnov.net>

(cherry picked from ffmpeg commit 31619584)
Signed-off-by: Anton Khirnov <anton@khirnov.net>

(cherry picked from ffmpeg commit 0d249316)
Signed-off-by: Anton Khirnov <anton@khirnov.net>

(cherry picked from ffmpeg commit 9ca44067)
Signed-off-by: Anton Khirnov <anton@khirnov.net>

(cherry picked from ffmpeg commit 7b42036b)
Signed-off-by: Anton Khirnov <anton@khirnov.net>

All encoders set pts and dts properly now (and have been doing that for
a while), so there is no good reason to do any timestamp guessing in the
muxer.

The newly added AVStreamInternal will be later used for storing all the
private fields currently living in AVStream.

It will be needed in other functions.

The reasoning for setting it to zero only applies to demuxing.