<html><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><META name="Author" content="Novell GroupWise WebAccess"></head><body style='font-family: Helvetica, Arial, sans-serif; font-size: 13px; '><div style="font-family: Tahoma, sans-serif; font-size: 13px; ">Hi Ross,</div><div style="font-family: Tahoma, sans-serif; font-size: 13px; "><br></div><div style="font-family: Tahoma, sans-serif; font-size: 13px; ">Firstly, I apologise for the missing subject in the previous post. The Novell email software seems to screwing up my outgoing mail every now and then. </div><div style="font-family: Tahoma, sans-serif; font-size: 13px; ">Apologies in advance if it happens again.</div><div style="font-family: Tahoma, sans-serif; font-size: 13px; "><span style="font-size: 13px; "> </span></div><div><finlayson@live555.com><span style="font-family: Tahoma, sans-serif; font-size: 13px; ">> If you ever see the error message</span><br><font face="Tahoma, sans-serif" size="2">> sendRTPOverTCP: failed!</font><br><font face="Tahoma, sans-serif" size="2">> then this shows that the server's writes to the TCP socket are eventually overflowing the OS's internal buffer (which should be at least 50 kBytes), which in turn implies that your stream's bitrate is greater than the data capacity of the TCP connection. In this case there is nothing that you can do other than decrease the bitrate of your stream.</font><br> <br><div><finlayson@live555.com style="font-family: Tahoma, sans-serif; font-size: 13px; ">I looked through the logs and that message does appear but only sometime later (see mss.log). </finlayson@live555.com></div><div><finlayson@live555.com style="font-family: Tahoma, sans-serif; font-size: 13px; ">- Streaming starts around </finlayson@live555.com><span style="font-family: Tahoma, sans-serif; font-size: small; ">11:41:28.851871. </span></div><div><span style="font-family: Tahoma, sans-serif; font-size: small; ">- The '</span><span style="font-family: Tahoma, sans-serif; ">sendRTPOverTCP: failed</span><span style="font-family: Tahoma, sans-serif; ">' failed message appears somewhere around </span><font face="Tahoma, sans-serif">11:42:57.829415 so more than a minute and a half later. </font></div><div><font face="Tahoma, sans-serif">- However I would expect the RTSP 200 OK to be processed very much sooner than that and streaming should have started. </font></div><div><font face="Tahoma, sans-serif">- Also, like I mentioned we have increased the TCP send buffer sizes so that the stream does not fail on start-up.</font></div><br><div><div style="font-size: 13px; font-family: Tahoma, sans-serif; ">A colleague of mine was so kind as to run all the software on the local network and send me the logs. I've been staring at them and I think I may have an idea of what's going wrong.</div></div><br></finlayson@live555.com></div><div style="font-family: Tahoma, sans-serif; font-size: 13px; "><finlayson@live555.com>Now I don't know the live555 code well enough, but tell me what you think of the following: as far as I understand there are various handlers for the </finlayson@live555.com></div><div style="font-family: Tahoma, sans-serif; font-size: 13px; "><finlayson@live555.com>different types of incoming data, one for incoming RTSP messages, and one for RTP/RTCP over TCP starting with a '$'. </finlayson@live555.com></div><div style="font-family: Tahoma, sans-serif; font-size: 13px; "><finlayson@live555.com>The $ handler processes the incoming data and then calls either the RTP or the RTCP handler to process the rest of the message.</finlayson@live555.com></div><div style="font-family: Tahoma, sans-serif; font-size: 13px; "><finlayson@live555.com><br></finlayson@live555.com></div><div style="font-family: Tahoma, sans-serif; font-size: 13px; "><finlayson@live555.com>Could it be that once the client starts processing the RTP data i.e. before the 200 OK of the PLAY arrives, that the handler is then set to the $ (RTP/RTCP handler) and that </finlayson@live555.com></div><div style="font-family: Tahoma, sans-serif; font-size: 13px; "><finlayson@live555.com>if an RTSP message comes in, even though it gets processed, it's callback/completion handler is not invoked since the socket handling code is now in a "processing $" state?</finlayson@live555.com></div><div style="font-family: Tahoma, sans-serif; font-size: 13px; "><finlayson@live555.com><br></finlayson@live555.com></div><div style="font-family: Tahoma, sans-serif; font-size: 13px; "><finlayson@live555.com>My reasoning is as follows:</finlayson@live555.com></div><div style="font-family: Tahoma, sans-serif; font-size: 13px; "><finlayson@live555.com><br></finlayson@live555.com></div><div style="font-family: Tahoma, sans-serif; font-size: 13px; "><finlayson@live555.com>Looking at the wireshark dump on the client device (client-network.dump):</finlayson@live555.com></div><div><finlayson@live555.com style="font-family: Tahoma, sans-serif; font-size: 13px; ">- Network message 73 contains both the interleaved data and the RTSP PLAY response with sequence number 6. </finlayson@live555.com></div><div><finlayson@live555.com style="font-family: Tahoma, sans-serif; font-size: 13px; "> Following RTSP message is the $ character and a another 4 characters further there are the characters "apX~" where X=d2. </finlayson@live555.com></div><div><finlayson@live555.com style="font-family: Tahoma, sans-serif; font-size: 13px; "><br></finlayson@live555.com></div><div><finlayson@live555.com style="font-family: Tahoma, sans-serif; font-size: 13px; ">- Now looking at client.live555.log around line 9402 you can see the RTSP response with SN 6 being received by live555. </finlayson@live555.com></div><div><finlayson@live555.com style="font-family: Tahoma, sans-serif; font-size: 13px; "> In lines 9411-9427 you can see the </finlayson@live555.com><span style="font-family: Tahoma, sans-serif; font-size: 13px; ">"apX~" which matches the wireshark log. </span></div><div><span style="font-family: Tahoma, sans-serif; font-size: 13px; "> The '$' header never appeared the additional output logging since I assume that it got handled somewhere else in the code explaining why I couldn't find the $ sign previously. </span></div><div><span style="font-family: Tahoma, sans-serif; font-size: 13px; "> The data continuously being printed in </span><span style="font-family: Tahoma, sans-serif; font-size: 12.800000190734863px; ">client.live555.log is the content of fResponseBuffer from RTSPClient.cpp. </span></div><div><span style="font-family: Tahoma, sans-serif; font-size: 12.800000190734863px; "> The fact that in line 9411 the 200 OK has been removed from the buffer would indicate that live555 has processed that message.</span><span style="font-family: Tahoma, sans-serif; font-size: 13px; "> </span></div><div><span style="font-family: Tahoma, sans-serif; font-size: 13px; "> Therefore the VLC code should also have processed the 200 OK a</span><span style="font-family: Tahoma, sans-serif; font-size: 12.800000190734863px; ">round this point in time</span><span style="font-family: Tahoma, sans-serif; font-size: 13px; ">, but this never happens (see client.VLC.log). Typically at some point VLC reports: </span></div><div><span style="font-family: Tahoma, sans-serif; font-size: 13px; "><div> 'E/VLC (18053): [0x2dbda8]: live555 demux RTSP PLAY failed RTSP response was truncated. Increase "RTSPClient::responseBufferSize"'</div></span></div><div><span style="font-family: Tahoma, sans-serif; font-size: 13px; "><br></span></div><div><span style="font-family: Tahoma, sans-serif; font-size: 13px; ">- At line 17730 the '</span><font face="Tahoma, sans-serif"> RTCPInstance error: Hit limit when reading incoming packet over TCP. Increase "maxRTCPPacketSize"' message starts flooding the log file which eventually hangs VLC. </font></div><div><span style="font-family: Tahoma, sans-serif; "> This all seems to indicate that the live555 is still actively processing incoming data: I think that the main issue is that the PLAY callback never returns, </span></div><div><span style="font-family: Tahoma, sans-serif; "> which seems to indicate that if the live555 code has started processing RTP/RTCP over TCP data, the 200 OK is ignored somehow.</span></div><div><font face="Tahoma, sans-serif"><br></font></div><div><font face="Tahoma, sans-serif">Any thoughts on this?</font></div><div><font face="Tahoma, sans-serif">Please let me know If you want me to try out any fixes, add logging, etc.</font></div><div><font face="Tahoma, sans-serif"><br></font></div><div><font face="Tahoma, sans-serif">Regards,</font></div><div><font face="Tahoma, sans-serif">Ralf</font></div><div><font face="Tahoma, sans-serif"><br></font></div><div><font face="Tahoma, sans-serif"><br></font></div><div><font face="Tahoma, sans-serif"><br></font></div><div><font face="Tahoma, sans-serif"><br></font></div><font face="Verdana,Arial,Helvetica,Trebuchet MS" size="1">
<br />--
<br />This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
<br />The full disclaimer details can be found at <a href="http://www.csir.co.za/disclaimer.html">http://www.csir.co.za/disclaimer.html</a>.
<p>
<br />This message has been scanned for viruses and dangerous content by <a href="http://www.mailscanner.info/"><b>MailScanner</b></a>,
<br />and is believed to be clean.
<p>
<br />Please consider the environment before printing this email.
</font>
</body></html>