Based on a suggestion by Martin Panter. This is more descriptive,
since it's the actual timestamp field from the RTMP packet,
which might or might not be a delta depending on context (in
some packets it's a delta, in some packets it's an absolute
timestamp, and in some packets it's 0xffffff to indicate that
the actual delta or absolute timestamp is transmitted separately).
Signed-off-by: Martin Storsjö <martin@martin.st>
Related fix in "rtmpdump":
https://repo.or.cz/w/rtmpdump.git/commitdiff/79459a2
Adobe's RTMP specification (21 Dec 2012), section 5.3.1.3 ("Extended
Timestamp"), says "this field is present in Type 3 chunks". Type 3 chunks are
those with the one-byte header size.
This resolves intermittent hangs and segfaults caused by the read function,
and also includes an untested fix for the write function.
The read function was tested with ABC (Australia) News 24 streams, however
they are probably restricted to only Australian internet addresses. Some of
the packets at the start of these streams seem to contain junk timestamp
fields, often requiring the extended field. Test command:
avplay rtmp://cp81899.live.edgefcs.net/live/news24-med@28772
Signed-off-by: Martin Storsjö <martin@martin.st>
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>
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>
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>
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>
Before this, almost all module groups have been used for grouping functions
and fields in structures semantically. This causes them to not appear
properly in the file documentation and needlessly clutters up the "Modules"
index.
Additionally, this commit streamlines some spelling and appearances.
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
