It is not supposed to be done outside lavc.

This is basically a revert of 818062f2.

It is unclear what issue this was supposed to fix, if it reappears again
it will have to be fixed in a more proper place.

The wtv-demux test change is because the sample starts with a B-frame.

We read sub_packet_h / 2 packets per line of data (during deinterleaving),
which equals zero if sub_packet_h <= 1, thus causing us to not read any
data, leading to an infinite loop.

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org

Signed-off-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>

Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>

Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>

This allows writing QuickTime-compatible fragmented mp4 (with
a non-empty moov atom) to a non-seekable output.

This buffers the mdat for the initial fragment just as it does
for all normal fragments, too. Previously, the resulting
atom structure was mdat,moov, moof,mdat ..., while it now
is moov,mdat, moof,mdat.
Signed-off-by: Martin Storsjö <martin@martin.st>

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

Also split a long line.
Signed-off-by: Martin Storsjö <martin@martin.st>

In nonseekable files, we already stop parsing the toplevel atoms
after finding moov and one mdat. In large seekable files (or files
that are seekable, but slowly, e.g. http), reading all the fragments
at the start can take a considerable amount of time. This allows
opting out from this behaviour.
Signed-off-by: Martin Storsjö <martin@martin.st>

If parsing moov+mdat in a non-seekable file, we currently
abort parsing directly after parsing the header of the mdat
atom. If we want to continue parsing later (if looking to
parse later fragments), we need to skip past the content of the
mdat atom, otherwise we end up parsing the content of the mdat
atom as root level atoms.
Signed-off-by: Martin Storsjö <martin@martin.st>

The operations that use it require it to be promoted to a larger (natural)
type and thus perform sign extension on it.

While an optimal compiler may account for this, gcc 4.6 (for x86 Windows)
fails. Using the natural integer type provides a 2% speedup for Win64
and 1% for Win32.
Signed-off-by: Diego Biurrun <diego@biurrun.de>

Fixes a memleak.

Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>

Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>

This allows encoders to set pts and/or duration even if they do not use
CODEC_CAP_DELAY.

Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>

Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>

Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>

Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>

The AVOptions based default to threads auto in 2473a45c
works only if avplay does not use custom option handling
for -threads.

CC: <libav-stable@libav.org>

Signed-off-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Janne Grunau <janne-libav@jannau.net>

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

Signed-off-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Diego Biurrun <diego@biurrun.de>

For video, mark the first sample in a trun which doesn't have the
sample-is-non-sync-sample flag set as a keyframe.

In particular, the "sample does not depend on other samples" flag
isn't enough to make it a keyframe, since later frames still can
reference frames prior to that one (the flag only says that that
particular frame doesn't depend on other frames).

This fixes bug 215.
Signed-off-by: Martin Storsjö <martin@martin.st>

This prevents having to sign-extend on 64-bit systems with 32-bit ints,
such as x86-64. Also fixes crashes on systems where we don't do it and
arguments are not in registers, such as Win64 for all weight functions.

Output packet size should match avctx->block_align. The target output packet
size is 1024 bytes.
Before:
mono   - 1024 samples -> 512 bytes
stereo - 2048 samples -> 2048 bytes
After:
mono   - 2048 samples -> 1024 bytes
stereo - 1024 samples -> 1024 bytes