Re: [Gnash-dev] iPlayer using gnash

[Matthew Spencer]

Some more info on my investigations:

The iPlayer code seems to take the form (excuse my poor actionscript, assume its pseudo code)

NetConnection nc=new NetConnection();
nc. (o) {
  if(o == NetConnection.Connect.Success) {
    NetStream ns(nc);
    // Do something with the connection
  }
  // This is where the NetStream o
}

nc.connect(...)

The point here is that the NetStream is only created after a successful connection to the server.  My feeling is that this should be signalled after the Invoke::connect response is returned from the server.  The current code only attempts to make a connection when NetConnection::call is called, which will never happen in the code sample above.  I therefore plan to issue the handshake and Invoke::connect when NetConnection::connect is called

Secondly, the current rtmp_client code has a hardcoded value for swfUrl for the version of RTMPClient::encodeConnect that is used when generating the Invoke::connect call.  Through investigation, I can prove that the iPlayer servers are sensitive to this value being correct, so I plan to add a new version of the call that allows me to define a proper version for swfUrl.

Any comments on what I have said?

Matt

2009/9/16 Matthew Spencer <address@hidden>

Ok, I have changed over to using RTMPClient::connectToServer(), but I am experiencing the same problem.

Looking at packed dumps between flvsttreamer and gnash, there is a clear difference in RTMP  Handshake part 3 (as reported by WireShark).

flvstreamer:
  Me->Server:  RTMP Handshake phase 1 (random payload)
  Server->Me:  RTMP Handshake phase 2 (random payload from server + my initial payload)
  Me->Server:  RTMP Handshake phase 3 (echo of random payload from server)
  Me->Server:  RTMP Invoke connect

gnash:
  Me->Server:  RTMP Handshake phase 1 (random payload)
  Server->Me:  RTMP Handshake phase 2 (random payload from server + my initial payload)
  Me->Server:  RTMP Handshake phase 3 (echo of random payload from server) + connect

The connect is not being sent with the handshake response from me in flvstreamer, instead as a separate packet.  Does anyone have any views on this?  I am going to investigate changing the RTMP_Client code to reflect this and will let you know what happens.

Mat

2009/9/15 Rob Savoye <address@hidden>

On 09/15/09 12:01, Matthew Spencer wrote:

Quick status update, I am at the point where the initial handshake seems to
be working now.  I am not getting a vaild response to the 'connect' packet
sent.

 Then the packet you sent isn't 100% correct. This usually happens if you miss the 128 byte boundary for RTMP chunks, in this case it should be a 0xc3 exactly 128 bytes after the 12 byte header. the NetConnection packet is usually over 128 bytes, so it gets split into two pieces.

Try the RTMPClient::connectToServer() method, which should be doing this for you.

       - rob -