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.onStatus = function (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 <[email protected]>
> 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 <[email protected]>
>
>> 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 -
>>
>
>
_______________________________________________
Gnash-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnash-dev
