In order to send or receive a stream FCPublish, FCSubscribe and _checkbw
are completely optional and often not implemented. releaseStream over a
non-existen stream might report an error instead of being silent.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Not all compilers support ssize_t (MSVC doesn't), and none of these
variables need to be larger than 32 bit.
Signed-off-by: Martin Storsjö <martin@martin.st>
Specifies how the server verifies client SWF files before allowing the
files to connect to an application. Verifying SWF files is a security
measure that prevents someone from creating their own SWF files that can
attempt to stream your resources.
Signed-off-by: Martin Storsjö <martin@martin.st>
The _checkbw calls were changed to use transactionId 0 in commit
82613564 so that servers would not return _result/_error about it.
While this is the strict interpretation of the spec, there are
servers that return _error about it, even if transactionId was 0.
The latest version of EvoStream Media Server (the commercial version
of crtmpserver) behaves properly as described, i.e. returning an
_error normally but not returning anything when using transactionId
0. The latest version of crtmpserver (right now at least) doesn't
behave like this though, it returns an error even if transactionId
was 0.
There are also other servers that return errors even if transactionId
is set to 0. Therefore set a proper transaction id so that the invoke
can be tracked and the error properly ignored instead.
Signed-off-by: Martin Storsjö <martin@martin.st>
When streaming live streams using the Akamai, Edgecast or Limelight CDN,
players cannot simply connect to the live stream. Instead, they have to
subscribe to it, by sending an FC Subscribe call to the server.
Signed-off-by: Martin Storsjö <martin@martin.st>
This makes sure these calls are removed by dead code elimination
even if optimization is disabled. This fixes building without
crypto libraries without optimization.
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>
Add a new option 'rtmp_flush_interval' that allows specifying the
number of packets to write before sending it off as a HTTP request.
This is mostly relevant for RTMPT - for plain RTMP, it only controls
how often we check the socket for incoming packets, which shouldn't
affect the performance in any noticeable way.
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>
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>
This factorizes existing code into a new function gen_buffer_time(),
which generates the client buffer time message and sends it to the
server.
Signed-off-by: Martin Storsjö <martin@martin.st>
