This does not add support for any error resilience tools.

Container and lossy decoding by Aneesh Dogra <aneesh@sugarlabs.org>
Lossless decoding by Justin Ruggles <justin.ruggles@gmail.com>

Signed-off-by: Diego Biurrun <diego@biurrun.de>

Abort if it is invalid if strict error checking has been requested.

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

This makes the output fragments independent of their position in
the output stream, making the output work better when streamed.

QuickTime Player doesn't support fragmented mp4 without the base
data offset, though.
Signed-off-by: Martin Storsjö <martin@martin.st>

This is a bit more work, but avoids having to fill in
the data offset field afterwards instead of directly when
the rest of the trun atom is written.

This simplifies future cases where this field needs to be set to
something different.
Signed-off-by: Martin Storsjö <martin@martin.st>

This is required, since invalid parameters actually could
pass the switch check below.

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

A given packet won't always come in contiguously; sometimes
they may be broken up on chunk boundaries by packets of another
channel.

This support primarily involves tracking information about the
data that's been read, so the reader can pick up where it left
off for a given channel.

As a side effect, we no longer over-report the bytes read if
(toread = MIN(size, chunk_size)) == size
Signed-off-by: Martin Storsjö <martin@martin.st>

Since the number of channels is multiplied by 36 and assigned to
to a uint16_t, make sure this calculation didn't overflow. (In
certain cases the calculation could overflow leaving the
truncated block_align at 0, leading to divisions by zero later.)

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

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

prev_pkt[0] is used for input packets, while prev_pkt[1] is
used for output.
Signed-off-by: Martin Storsjö <martin@martin.st>

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

A change in framesize caused a perpetual loss of synchronization.
So read (and use) the frame size from the frame header instead of
setting it only once.
Signed-off-by: Diego Biurrun <diego@biurrun.de>

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

Also fix the typo in the last entry version.

This avoids crashes when initializing the range coder for
the first slice context.

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

This is similar to an existing check for the second-last frame
from 062421e3.

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

This avoids a potential division by zero.

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

Some files have the duration set to -1 in the mdhd atom, more
or less legitimately. (We produce such files ourselves, for the
initial duration in fragmented mp4 files.)

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

Also return a proper error code.

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

Also pass on any returned error code.

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

This more closely corresponds to the usage of the field.
Its usage here is unrelated to the channel ID.
Signed-off-by: Martin Storsjö <martin@martin.st>

Channel 4 is typically used by the Flash player to transmit
audio, channel 6 for video, and various stream-specific invokes
get sent over channel 8, which is designated the source channel.

This more closely matches the behavior of the Flash player,
including the transmission of play requests over channel 8.
Signed-off-by: Martin Storsjö <martin@martin.st>

Sending non-monotonic packets (e.g. when the audio and video
streams are monotonic within themselves but not muxed
monotonically) will lead to negative values the RTMP timestamp
field (where timestamps are transmitted only as deltas for each
channel), and this delta can end up being incorrectly written as
a large unsigned number.
Signed-off-by: Martin Storsjö <martin@martin.st>

This allows handling errors from av_realloc properly.
Signed-off-by: Martin Storsjö <martin@martin.st>

This is required since 187105ff when we started trying to
wrap this function as well.
Signed-off-by: Martin Storsjö <martin@martin.st>

Since 596e5d47, this is not necessary anymore. It also allows to
actually disable the flushing, improving write performance (but
possibly giving worse latency in real-time streaming).
Signed-off-by: Martin Storsjö <martin@martin.st>

This is enabled by default and can be disabled with
"-fflags -flush_packets".

Inspired by a patch from Nicolas George <nicolas.george@normalesup.org>.
Signed-off-by: Martin Storsjö <martin@martin.st>

It is used internally.

The onTextData is used to implement text data streams in flv.

Apparently a widely used streaming server requires that the second
field always presents a version during C1 phase.

Will be reused for supporting play.