Replicates lavf/librtmp.c behavior in L149-156 and rtmpdump's
behavior with "--swfVfy <url>" passing the url to swfUrl.
Fixes trac ticket #5549.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Replicates lavf/librtmp.c behavior in L145-152 and rtmpdump's
behavior with "--swfVfy <url>" passing the url to swfUrl.
Fixes bug 943.
Signed-off-by: Martin Storsjö <martin@martin.st>
This swaps which field is set when the Window Acknowledgement Size
and Set Peer BW packets are received, renames the fields in
order to clarify their role further and adds verbose comments
explaining their respective roles and how well the code currently
does what it is supposed to.
The Set Peer BW packet tells the receiver of the packet (which
can be either client or server) that it should not send more data
if it already has sent more data than the specified number of bytes,
without receiving acknowledgement for them. Actually checking this
limit is currently not implemented.
In order to be able to check that properly, one can send the
Window Acknowledgement Size packet, which tells the receiver of the
packet that it needs to send Acknowledgement packets
(RTMP_PT_BYTES_READ) at least after receiving a given number of bytes
since the last Acknowledgement.
Therefore, when we receive a Window Acknowledgement Size packet,
this sets the maximum number of bytes we can receive without sending
an Acknowledgement; therefore when handling this packet we should set
the receive_report_size field (previously client_report_size).
Signed-off-by: Martin Storsjö <martin@martin.st>
Also rename comments and log messages accordingly,
and add clarifying comments for some hardcoded values.
The previous names were taken from older, reverse engineered
references.
These names match the official public rtmp specification, and
matches the names used by wirecast in annotating captured
streams. These names also avoid hardcoding the roles of server
and client, since the handling of them is irrelevant of whether
we act as server or client.
The RTMP_PT_PING type maps to RTMP_PT_USER_CONTROL.
The SERVER_BW and CLIENT_BW types are a bit more intertwined;
RTMP_PT_SERVER_BW maps to RTMP_PT_WINDOW_ACK_SIZE and
RTMP_PT_CLIENT_BW maps to RTMP_PT_SET_PEER_BW.
Signed-off-by: Martin Storsjö <martin@martin.st>
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.
When bytes_read overflowed, last_bytes_read did not yet overflow
and no bytes-read report was created leading to a timeout.
Analyzed-by: Thomas Bernhard
Fixes ticket #5836.
Fix problem to fail by a RTMP Control Message except "Set Chunk Size (1)" after an RTMP handshake. When 'nginx-rtmp-module' relays an RTMP, it sends not only control message 'Set Chunk Size (1)' but also 'Window Acknowledgement Size (5)'.
Reviewed-by: Steven Liu <lingjiujianke@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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>
This should fix RTMP input which was broken by cbbd906be6
the 40 + 11 case is untested as it did not occur in the testcase
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
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>
In current versions of ffmpeg, when streaming to an RTMP server, anytime 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.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
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>
For URLs "rtmp://server[:port]/foo" determine what `foo` refers to. If
application name has been defined by the user assume that `foo` is a
playpath, otherwise assume application name.
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
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>
Josh Allmann
Derek Buitenhuis
Ricardo Constantino
Steven Liu
Diego Biurrun
Martin Storsjö
Luca Barbato
Carl Eugen Hoyos
Hiroyuki OYAMA
Vittorio Giovara
Anton Khirnov
Michael Niedermayer
James Almer
Paul B Mahol
Michael Niedermayer
Jeffrey Wescott
Kacper Michajłow
Alexander Drozdov
Uwe L. Korn