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>
This more closely corresponds to the usage of the field.
Its usage here is unrelated to the channel ID.
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>
Sending non-monotonic packets (e.g. when the audio and video
streams are monotonic within themselves but not muxed
monotonically) will lead to negative values the RTMP timestamp
field (where timestamps are transmitted only as deltas for each
channel), and this delta can end up being incorrectly written as
a large unsigned number.
Signed-off-by: Martin Storsjö <martin@martin.st>
When streaming to limelight, the app name is either a full
"appname/subaccount" or "appname/_definst_". In the latter case,
the app name can be simplified into simply "appname", but the
authentication hashing assumes the /_definst_ still to be present.
Signed-off-by: Martin Storsjö <martin@martin.st>
do_adobe_auth takes the parameters in the order "opaque, challenge".
Due to the way they are treated, this didn't matter in the tested
setups though - if both are set, we only use one. In the tested
setups (Wowza and Akamai) either one of them were null or they
were both set to the same value, which is why this worked before.
Signed-off-by: Martin Storsjö <martin@martin.st>
Limelight is a not too uncommon CDN. The authentication scheme is
pretty similar to the adobe authentication, but is even closer to
normal http digest authentication (but not close enough to warrant
sharing code) than the adobe version.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is mostly used to authenticate the client when publishing.
Tested with wowza and akamai.
Some but not all servers support resending a new connect invoke
within the same connection, so always reconnect for sending a new
connection attempt. This matches what other applications do as well.
The authentication scheme is structurally pretty similar to http
digest authentication, but uses base64 instead of hex strings.
Signed-off-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fixes: [FFmpeg-devel] rtmpproto compile error
Similar patch: [FFmpeg-devel] [PATCH] call to strncat replaced with av_strlcat to avoid compile issue with systems implementing strncat via strcat.
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>
Luca Barbato
Alexandra Khirnova
Josh Allmann
Martin Storsjö
Gavriloaie Eugen-Andrei
Kostya Shishkov
Diego Biurrun
Michael Niedermayer
Samuel Pitoiset
Jordi Ortiz