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

Gif demuxer is capable of extracting multiple frames from gif file.
In conjunction with gif decoder it implements support for reading
animated gifs.
Demuxer has two options available to user: default_delay and min_delay.
These options are for protection from too rapid gif animations. In practice
it is standard approach to slow down rendering of this kind of gifs. If you try to
play gif with delay between frames of one hundredth of second (100fps) using
one of major web browsers, you get significantly slower playback,
around 10 fps. This is because browser detects that delay value is less than some
threshold (usually 2 hundredths of second) and reset it to default value (usually 10
hundredths of second, which corresponds to 10fps). Manipulating these options user
can achieve the same effect during conversion to some video format. Otherwise user
can set them to not protect from rapid animations at all.
The other case when these options necessary is for gif images encoded according to
gif87a standard since prior to gif89a there was no delay information included in file.
Bump lavf minor version.

Signed-off-by: Vitaliy E Sugrobov <vsugrob@hotmail.com>

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

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

Also remove the duplicated #if.

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

Simplifies usage but has higher latency.

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

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

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

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

This muxer splits the output from the ismv muxer into individual
files, in realtime.

The same can also be done by the standalone tool ismindex, but this
muxer is needed for doing it in realtime (especially for live
streams that need extra handling for updating the lookahead fields
in the fragment headers).

Using this muxer, one can deliver live smooth streaming from a
normal static file web server. (Using ismindex, one can deliver
premade smooth streaming files from a static file web server,
or prepare files for serving with IIS.)

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

Signed-off-by: Michael Bradshaw <mbradshaw@sorensonmedia.com>
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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

This adds two protocols, but one of them is an internal implementation
detail just used as an abstraction layer/generalization in the code. The
RTMPE protocol implementation uses ffrtmpcrypt:// as an alternative to the
tcp:// protocol. This allows moving most of the lower level logic out
from the higher level generic rtmp code.

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

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

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

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

The prefix makes it easier to distinguish the proper end-user
protocols from the internal ones.

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

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

This simplifies usage for segment streaming formats with no global
headers, tipically MPEG 2 transport stream "ts" files.

The seg class duplication is required in order to avoid an infinite loop
in libavformat/utils.c:format_child_next_class().

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

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

This adds two protocols, but one of them is an internal implementation
detail just used as an abstraction layer/generalization in the code. The
RTMPT protocol implementation uses rtmphttp:// as an alternative to the
tcp:// protocol. This allows moving most of the lower level logic out
from the higher level generic rtmp code.

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

libnut is unmaintained and known to be buggy; native NUT code exists.

Signed-off-by: Jordi Ortiz <nenjordi@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Signed-off-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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

Keep the old protocol name around for backwards compatibility
until the next bump.

Deprecate the method of implicitly assuming the nested protocol.
For applehttp://server/path, it might have felt logical, but
supporting hls://server/path isn't quite as intuitive. Therefore
only support hls+http://server/path from now on.

Using this protocol at all is discouraged, since the hls demuxer
is more complete and fits into the architecture better. There
have been cases where the protocol implementation worked better
than the demuxer, but this should no longer be the case.

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

When this demuxer was created, there didn't seem to be any
consensus of a common short name for this protocol. Now
the consensus seems to be to call it hls.

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

This allows easily differentiating between both implementations within the build
system and combining the native implementation for plain RTMP with librtmp for
the RTMPE, RTMPS, RTMPT, RTMPTE protocol variants.

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

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

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

Signed-off-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

It behaves similarly to image2 muxer

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

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>