Normally, all channel ids are between 0 and 10, while they in
uncommon cases can have values up to 64k.

This avoids allocating two arrays for up to 64k entries (at a total
of over 6 MB in size) each when most of them aren't used at all.
Signed-off-by: Martin Storsjö <martin@martin.st>

And fix the AMF_DATA_TYPE_ARRAY parsing while at it.

A MIXEDARRAY type, as the ARRAY, store the number of elements in
an uint32 before the list. The ARRAY is strict and does not have
an OBJECT terminator, MIXEDARRAY behaves like an OBJECT type and
a different than stated number of element can be present.

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>

CC: libav-stable@libav.org

A negative `size' will bypass FFMIN().  In the subsequent memcpy() call,
`size' will be considered as a large positive value, leading to a buffer
overflow.

Change the type of `size' to unsigned int to avoid buffer overflow, and
simplify overflow checks accordingly. Also change a literal buffer
size to use sizeof, and limit the amount of data copied in another
memcpy call as well.
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>

Sanity checks like `data + size >= data_end || data + size < data' are
broken, because `data + size < data' assumes pointer overflow, which is
undefined behavior in C.  Many compilers such as gcc/clang optimize such
checks away.

Use `size < 0 || size >= data_end - data' instead.
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>

A negative `size' will bypass FFMIN().  In the subsequent memcpy() call,
`size' will be considered as a large positive value, leading to a buffer
overflow.

Change the type of `size' to unsigned int to avoid buffer overflow, and
simplify overflow checks accordingly.
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Sanity checks like `data + size >= data_end || data + size < data' are
broken, because `data + size < data' assumes pointer overflow, which is
undefined behavior in C.  Many compilers such as gcc/clang optimize such
checks away.

Use `size < 0 || size >= data_end - data' instead.
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This avoids having to concatenate them into one buffer before writing
them as AMF.
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

This makes sure all incoming packets are read and handled (and reacted
to) while sending an FLV stream over RTMP to a server. If there were
enough incoming data to fill the TCP buffers, this could potentially
make things block at unexpected places. For the upcoming RTMPT support,
we need to consume all incoming data before we can send the next
request.
Signed-off-by: Martin Storsjö <martin@martin.st>

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

Check malloc calls used by ff_rtmp_packet_create, unify error
handling and pass on error codes.
Signed-off-by: Martin Storsjö <martin@martin.st>

The existing functions defined in intfloat_readwrite.[ch] are
both slow and incorrect (infinities are not handled).

This introduces a new header with fast, inline conversion
functions using direct union punning assuming an IEEE-754
system, an assumption already made throughout the code.

The one use of Intel/Motorola extended 80-bit format is
replaced by simpler code sufficient under the present
constraints (positive normal values).

The old functions are marked deprecated and retained for
compatibility.
Signed-off-by: Mans Rullgard <mans@mansr.com>

Signed-off-by: Mans Rullgard <mans@mansr.com>

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

Some received packets can have size 0. The return value from
av_malloc(0) may be NULL, which is ok if the size was 0. On
OS X, however, the returned pointer is non-null but leads to
crashes when trying to free it.
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Mans Rullgard <mans@mansr.com>

Originally committed as revision 22277 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 21533 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 21532 to svn://svn.ffmpeg.org/ffmpeg/trunk

libavformat/rtmppkt.c:350: warning: unused variable ‘i’
libavformat/rtmppkt.c:349: warning: unused variable ‘base’

Originally committed as revision 20917 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 20799 to svn://svn.ffmpeg.org/ffmpeg/trunk

Patch by Sergiy (piratfmGMAIL)

Originally committed as revision 20728 to svn://svn.ffmpeg.org/ffmpeg/trunk

track timestamp difference as well.
Patch by Sergiy (mail.composeAddress("piratfm","gmail.com"))

Originally committed as revision 20714 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 20686 to svn://svn.ffmpeg.org/ffmpeg/trunk

difference, so make all read packets store absolute timestamp.
As a consequence, we don't need to track audio/video timestamps separately
any longer in protocol handler.

Originally committed as revision 20685 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 20684 to svn://svn.ffmpeg.org/ffmpeg/trunk

Extracted from patch by Sergiy in thread "[PATCH] rtmp-output"

Originally committed as revision 20683 to svn://svn.ffmpeg.org/ffmpeg/trunk

intermediate buffer for reading value instead in RTMP protocol handler.

Originally committed as revision 20682 to svn://svn.ffmpeg.org/ffmpeg/trunk

instead of assuming it should occur right at given position.
This helps finding human-readable error descriptions in RTMP server replies.

Originally committed as revision 20575 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 20482 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 20270 to svn://svn.ffmpeg.org/ffmpeg/trunk

Originally committed as revision 20269 to svn://svn.ffmpeg.org/ffmpeg/trunk