Re: [Gnash-dev] RTMP

[Rob Savoye]

On 12/29/09 13:21, Vishnu Viswanath wrote:
> To implement RTMP should we start studying how the other protocols are
> implemented ??

  I just migrated my RTMP branch to trunk, that should help some. This
has the changes to the client API like I had mentioned on IRC. I'll try
to make some updates to the doc on how it currently works. Basically
the rtmp.* files are the base class, with all shared functionality
between the client and server side. Then there is rtmp_client.*, which
does all client side of course. RTMPClient::connectToServer() now does
all the grunt work of establishing an RTMP connection. both rtmp.* and
rtmp_client.* are for encoding/decoding RTMP packets. The rtmp_msg.* is
the overall class that holds multiple RTMP packets with the transport
packet header.

  You can look at the "Peering" code in cygnal.cpp, which uses this to
connect to other RTMP servers. I just merged this feature in from my
branch, it'll let Cygnal distribute the load over a cluster by itself,
and will let me do some other useful things by acting as a bridge
between networks. So now Cygnal functions as both an RTMP client and server.

  I fixed those bugs with building the testcases in
testsuite/network.all that you had a problem with. I fixed the other
RTMP test cases while I was at it, everything tests valgrind clean. So
you'll want to update, this is all checked in as of revno #11741.

  My suggestion is to fix the currently broken rtmpget to use the newer
client side API to establish the RTMP connection, start the stream
playing, and then write each packet to disk. This will be much simpler
than jumping deep into Gnash right away. We can then fix any bugs in any
of the lower level code you find without having them obscured by Gnash's
whole code base.

  There are docs on RTMP on our wiki, the osflash website, and various
other places if you search around the net. To stay sane, you'll want to
learn about tcpdump, ngrep, and wireshark. Warning, wireshark has some
bugs in it's RTMP decoder, so it can fool you if you're not careful. I
primarily use ngrep and tcpdump. Anyway, this is so you can watch the
network traffic, which is the only way to see the raw packets. That way
you can see any decoding/encoding bugs by comparing the hex with what
should be there.

  For lots of hex decoding examples, look in the libnet.all/test_rtmp,
as it uses binary captures from the other player as test case data for
the RTMP decoding API.

  Briefly, you start by doing the handshake, whose final packet after
going back and forth is an AMF encoded NetConnection() object. This is
what establishes the connection. To start a stream you send a
NetStream() object, followed by a 'remoting call' of the
NetStream::play() method. Then the server sends the stream, with an RTMP
header every 'chunksize'. The RTMP protocol allows for multiple channels
on a single connection, so then those all have to be split apart into
each channel. For streaming though, it's pretty easy and only a few
channels are used. For example, the audio and video are on separate
channels. 02 is always the system channel.

  The server can also issue a 'new chunksize' command, which it usually
does in the beginning, to change the packet size from the default
128bytes, often to 4096 or 1448. Bigger chunks means less processing, so
better performance. There are functions for all of this in the client
side API.

  As you figure things out, I'd appreciate expanding the documentation
in the manual and our wiki. I've obviously been focusing more on code
than docs.

        - rob -