[rtmpdump] r189 - in trunk: rtmp.c rtmp.h rtmpdump.c rtmpsuck.c streams.c

Howard Chu hyc at highlandsun.com
Tue Jan 5 23:19:26 CET 2010

compn wrote:
> On Tue, 05 Jan 2010 00:09:49 -0800, Howard Chu wrote:
>> hyc wrote:
>>> Author: hyc
>>> Date: Tue Jan  5 04:46:39 2010
>>> New Revision: 189
>>> Log:
>>> Add optional packet param to RTMP_Connect(); rtmpsuck will just send
>>> the original connect packet instead of generating its own.
>> I found a site that was using 3 separate auth strings following the main
>> Connect parameters. The SendConnectPacket() code only knew how to send 1
>> boolean flag + 1 auth string. (And we still don't know the meaning of that
>> boolean...) So as a quick fix, rtmpsuck now just sends the client's packet
>> straight through to the server. (That's always more reliable anyway...)
> old idea: use rtmpsrv to dump out all connect params into an
> rtmpdump command line for easy copy paste
> new idea: use rtmpsrv to dump connect packet sent by
> flash client for use with rtmpdump --usepacket bla.pkt
> of course, maybe it is completely the wrong idea...

It's kind of the same idea as rtmpsuck, just in two separate parts. Re-using
the entire connect packet isn't as good a solution here, because it may use
AMF3 and rtmpdump currently doesn't generate AMF3 requests. So it still comes
down to being able to specify the auth parameters individually. (Or we add
full AMF3 support to the code. That's more work, but probably a useful thing
to have in the long run.)

>> But, this presents an odd problem for rtmpdump; we need a way to specify
>> arbitrary auth parameters on the command line otherwise we're going to be
>> stuck with some sites that rtmpsuck works for that can't be accessed using
>> rtmpdump.
> rtmpsuck with full bandwidth download would be a good option for that.
> tho i am not sure how to handle it, probably just ignore/kill flash
> client instead of trying to buffer it.

Yeah, I guess we could do that. I'm leery of it because there's always the
chance the server will ask the client for something else in the middle of a
session. The safest thing to do to guarantee success is to keep the real
client in the loop, and do what we can to make the proxy more transparent.

Currently the big blocker is that the proxy only processes complete packets,
which imposes a pretty noticeable latency. We should be passing chunks back
and forth instead; that will improve the consistency of response times. But it
will require more tracking to figure out which packets we need to act on and
which we just pass thru/ignore.

>> I'm thinking of defining a new --auth option which takes a prefix defining the
>> type, followed by a value, which can be specified multiple times.
>> E.g. --auth B:1 --auth S:"some string value" --auth N:1234.567
>> (B for boolean, S for string, N for number)
>> All the evidence indicates that we need to be able to specify an arbitrary
>> number of auth parameters, of arbitrary type, instead of the two items we
>> currently have hardcoded. (And yes, we already have an --auth option right
>> now, my point is that we need to change its behavior.)
> ugh. now i'm trying to think how other rtmp implementations (ffmpeg)
> will handle this. ffmpeg developer had this to say about rtmp:
> "if we ignore it, maybe it will just go away".

Heh. Always an interesting question, support the crap designs or not. In this
case I think flash/rtmp is too entrenched to just go away, but who knows. Most
of the web sites using rtmp don't actually get any benefit from it, and
they're paying a large license fee to have a flash server, perhaps they'll
come to see the light...

More information about the rtmpdump mailing list