This test uses an existing FATE sample (h264/interlaced_crop.mp4).
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

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

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

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

This restores indentation after 65b875d8.
Signed-off-by: Martin Storsjö <martin@martin.st>

Doxygen 1.7.5.1 had been used as reference while certain distributions
provide older and not fully compatible versions.

Signed-off-by: Janne Grunau <janne-libav@jannau.net>

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

This is mandated in draft-pantos-http-live-streaming-07, section
6.3.4.
Signed-off-by: Martin Storsjö <martin@martin.st>

According to draft-pantos-http-live-streaming-07, 6.3.4,
the duration of the last media segment in the playlist
should be used as initial minimum reload delay.
Signed-off-by: Martin Storsjö <martin@martin.st>

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

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

With the current default PES packet size, and very small audio bitrates,
audio packet duration gets too long. For players, which wait for a whole
audio packet (or more) it takes a very long time to start playing sound.

For 24kbps audio, one PES packet is about 1 second long. On Motorola STBs,
we observe about 3 second delay before the playback starts with the
default setting.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Do not assume the audio packets being always smaller than
DEFAULT_PES_PAYLOAD_SIZE.
Signed-off-by: Jindřich Makovička <makovick@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Kostya Shishkov <kostya.shishkov@gmail.com>

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

Originally, prior to 8742a4ff, the caller code was compiled
within this condition:

ARCH_X86 && HAVE_7REGS && HAVE_EBX_AVAILABLE && !defined(BROKEN_RELOCATIONS)

Since HAVE_7REGS is defined as
(ARCH_X86_64 || (HAVE_EBX_AVAILABLE && HAVE_EBP_AVAILABLE))
the subcondition HAVE_7REGS && HAVE_EBX_AVAILABLE is equal
to HAVE_7REGS (for 32 bit at least). The correct simplification
of the original condition thus is HAVE_7REGS, not
HAVE_EBX_AVAILABLE.

This fixes compilation in some cases where HAVE_EBP_AVAILABLE = 0
and HAVE_EBX_AVAILABLE = 1.
Signed-off-by: Martin Storsjö <martin@martin.st>