* commit 'b97b1adb3f807e1acd00d56319ee6cb41cc727e4':
rtmpproto: Add a comment explaining the logic in handle_notify
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'dc4acc820076b2149ef6c921bdabe05d07ca1bc6':
rtmpproto: Extend a comment to explain the prev_pkt arrays roles
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '647d655d19c38e9716328e4787199149097d6089':
rtmpproto: Consistently use the right prev_pkt array
Merged-by: Michael Niedermayer <michaelni@gmx.at>
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>
* commit 'd4aef997809167832ecc64e89dda8cb445e5fe10':
rtmp: Follow Flash player numbering for channels.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'fe0337e89bbbe84b7274fbb0d9d56ed992937931':
rtmp: Do not send the first field twice within the handshake
Merged-by: Michael Niedermayer <michaelni@gmx.at>
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>
* commit '8e1fe345577a42f99591caf8a06c447613449694':
rtmp: Detect and warn if the user tries to pass librtmp style parameters
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '28306e6d620c109ddd672f7243adfbc2bbb3b18f':
network: factor out bind-listening code
use my full first name instead of short one in copyrights
Conflicts:
libavformat/tcp.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'b3ea76624ad1baab0b6bcc13f3f856be2f958110':
vf_aspect: use the name 's' for the pointer to the private context
Remove commented-out debug #define cruft
Conflicts:
libavcodec/4xm.c
libavcodec/dvdsubdec.c
libavcodec/ituh263dec.c
libavcodec/mpeg12.c
libavfilter/avfilter.c
libavfilter/vf_aspect.c
libavfilter/vf_fieldorder.c
libavformat/rtmpproto.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
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>
