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 - _______________________________________________ Gnash-dev mailing list Gnash-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnash-dev