Servers seem to be happy to receive the wrapped-around value as long
as they receive a report, otherwise they timeout.
Initially reported and analyzed by Thomas Bernhard.
According to the public RTMP specification, these 4 bytes should
be zero.
librtmp in server mode assumes that the RTMPE (FP9) handshake is
used if these bytes are nonzero.
Signed-off-by: Martin Storsjö <martin@martin.st>
When acting as server, the server can include a "clientid" property
in some status messages. But this should be a unique number
identifying the client session, not identifying the server itself.
In practice, omitting it works just as well as including this
incorrect field.
Signed-off-by: Martin Storsjö <martin@martin.st>
This makes sure that e.g. Adobe FME actually reacts to it. As long
as the value we've been sending is the default one (128), the bug
hasn't been noticed.
Signed-off-by: Martin Storsjö <martin@martin.st>
Some applications such as Adobe FME append lots of parameters
here, making it easily overflow the current limit.
Signed-off-by: Martin Storsjö <martin@martin.st>
Since all URLContexts have the same AVOptions, such AVOptions
will be applied on the outermost context only and removed from the
dict, while they probably make sense on all contexts.
This makes sure that rw_timeout gets propagated to the innermost
URLContext (to make sure it gets passed to the tcp protocol, when
opening a http connection for instance).
Alternatively, such matching options would be kept in the dict
and only removed after the ffurl_connect call.
Signed-off-by: Martin Storsjö <martin@martin.st>
Instead of a linked list constructed at av_register_all(), store them
in a constant array of pointers.
Since no registration is necessary now, this removes some global state
from lavf. This will also allow the urlprotocol layer caller to limit
the available protocols in a simple and flexible way in the following
commits.
In one case it was written as zero, one case left it uninitialized,
missed the 11 bytes for the flv header.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Currently, when streaming to an RTMP server, any time a packet of type
RTMP_PT_NOTIFY is encountered, the packet is prepended with @setDataFrame
before it gets sent to the server. This is incorrect; only packets for
onMetaData and |RtmpSampleAccess should invoke @setDataFrame on the RTMP
server. Specifically, the current bug manifests itself when trying to
stream onTextData or onCuePoint invocations.
This fix addresses that problem and ensures that the @setDataFrame is
only prepended for onMetaData and |RtmpSampleAccess.
Since data is fed to the rtmp_write function in smaller pieces (depending
on the calling IO buffer size), we can't generally assume that the
whole packet (or even the whole command string) is available at once,
therefore we can only check the command string once the full packet
has been transferred to us for sending.
Based on a patch by Jeffrey Wescott.
Signed-off-by: Martin Storsjö <martin@martin.st>
It is never an error if this method failed. If rt->live was
explicitly set to 0 (known to be a recorded file), print it
as a warning, otherwise print it as a debug message.
Based on a patch by Michael Niedermayer.
Signed-off-by: Martin Storsjö <martin@martin.st>
Prevent possible memory leaks.
Connect to nginx and request a non-existent resource to
trigger the issue.
CC: libav-stable@libav.org
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Uwe L. Korn <uwelk@xhochy.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Some RTMP commands need the most recent timestamp as their parameter, so
keep track of it. This must be the most recent one and not e.g. the max
received timestamp as it can decrease again through seeking.
Signed-off-by: Martin Storsjö <martin@martin.st>
In (non-live) streams with no metadata, the duration of a stream can
be retrieved by calling the RTMP function getStreamLength with the
playpath. The server will return a positive duration upon the request if
the duration is known, otherwise either no response or a duration of 0
will be returned.
Signed-off-by: Martin Storsjö <martin@martin.st>
Packets that contain a number as a result to a rtmp function call are
structured the same way (String, Number, Null, Number). This new method
also includes more bounds checks to better handle packets that are not
structured as expected.
Signed-off-by: Martin Storsjö <martin@martin.st>
In the presence of no metadata, do not set any stream flag in the FLV
header but let the demuxer handle the detection and creation of streams
as data arrives.
Signed-off-by: Martin Storsjö <martin@martin.st>
Support the URL scheme where the playpath is in an RTMP URL is
passed as the slist argument and the app is given infront of the
query part of the URL:
rtmp://host[:port]/[app]?slist=[playpath]
(other arguments in the query part are stripped as they are not used)
Signed-off-by: Martin Storsjö <martin@martin.st>
In all other cases where ff_rtmp_packet_read is used, the packet returned
is passed to rtmp_parse_result more or less immediately. In this single
case, the content of the packet was required to be a connect packet.
Some clients, e.g. Open Broadcaster Software, send a chunk size packet
before the connect packet. If the first packet is a chunk size packet,
handle it and read another one, requiring this to be a connect packet
instead.
Signed-off-by: Martin Storsjö <martin@martin.st>
Previously, if read_connect failed, the ret variable was unmodified
and had the value 0, indicating success, which then was returned from
the rtmp_open function, even though it actually failed.
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>
If the url ends with .flv, we stripped it but didn't initialize
rt->playpath, doing av_strlcat on an uninitialized buffer.
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>
This wasn't an issue prior to 58404738, when the whole RTMP packet
was copied at once and the length of the individual embedded flv
packets only were validated by the flv demuxer.
Prior to this patch, this could lead to reads and writes out of bound.
Signed-off-by: Martin Storsjö <martin@martin.st>
If the embedded flv packets were incomplete and we aborted the
copying loop early, make sure the flv buffer is trimmed to
only contain full packets.
Signed-off-by: Martin Storsjö <martin@martin.st>
update_offset is also called from handle_metadata, where the
packet header sizes is already included in the size.
Previously this lead to flv_data/flv_size including 15 uninitialized
bytes at the end after each call to handle_metadata, making the
flv demuxer lose sync with the stream.
Also remove leftover copying in handle_metadata. This is a leftover
from the refactoring in 5840473. (Previously this final mempcy was
the one that copied all the packets at once, while this is done
within the loop right now.) After making sure flv_size is set to
the right size, this write was out of bounds.
Signed-off-by: Martin Storsjö <martin@martin.st>
This was overlooked in d872fb0f7 since I assumed all the realloc
issues in the rtmp code was fixed already.
Signed-off-by: Martin Storsjö <martin@martin.st>
The current magic numbers passed are values in seconds, while the
parameter itself should be passed over the wire in milliseconds.
This makes (some/all?) live streams from Red5 work correctly, that
previously returned StreamNotFound even with "-rtmp_live live". After
this commit, the default 'any' also works on these streams.
Signed-off-by: Martin Storsjö <martin@martin.st>
On (certain streams/setups at least on) Red5, the description string
actually is present, but empty. Therefore, first try loading the
description, but if not found or empty, load the code string instead.
The code string is quite understandable in most cases anyway (like
"NetStream.Play.StreamNotFound").
Signed-off-by: Martin Storsjö <martin@martin.st>
When av_reallocp fails, the associated variables that keep track of
the number of elements in the array (and in some cases, the
separate number of allocated elements) need to be reset.
Not all of these might technically be needed, but it's better to
reset them if in doubt, to make sure variables don't end up
conflicting.
Signed-off-by: Martin Storsjö <martin@martin.st>
Use update_offset() as done for rtmp audio, video and notifications and
read update and write the fields instead of replacing them in the rtmp
packet and then memcpying it to the output buffer.
Luca Barbato
Diego Biurrun
Martin Storsjö
Vittorio Giovara
Anton Khirnov
Michael Niedermayer
James Almer
Alexander Drozdov
Uwe L. Korn
Gabriel Dume
Stephan Soller