[Live-devel] Re (your issues with RTP-over-TCP streaming)

[Ralf Globisch]

Hi Ross,


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. 
Apologies in advance if it happens again.
 
> If you ever see the error message
>     sendRTPOverTCP: failed!
> 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.
 
I looked through the logs and that message does appear but only sometime later (see mss.log). 
- Streaming starts around 11:41:28.851871. 
- The 'sendRTPOverTCP: failed' failed message appears somewhere around 11:42:57.829415 so more than a minute and a half later. 
- However I would expect the RTSP 200 OK to be processed very much sooner than that and streaming should have started. 
- Also, like I mentioned we have increased the TCP send buffer sizes so that the stream does not fail on start-up.


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.




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 
different types of incoming data, one for incoming RTSP messages, and one for RTP/RTCP over TCP starting with a '$'. 
The $ handler processes the incoming data and then calls either the RTP or the RTCP handler to process the rest of the message.


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 
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?


My reasoning is as follows:


Looking at the wireshark dump on the client device (client-network.dump):
- Network message 73 contains both the interleaved data and the RTSP PLAY response with sequence number 6. 
  Following RTSP message is the $ character and a another 4 characters further there are the characters "apX~" where X=d2. 


- Now looking at  client.live555.log around line 9402 you can see the RTSP response with SN 6 being received by live555. 
  In lines 9411-9427 you can see the "apX~" which matches the wireshark log. 
  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. 
  The data continuously being printed in client.live555.log is the content of fResponseBuffer from RTSPClient.cpp. 
  The fact that in line 9411 the 200 OK has been removed from the buffer would indicate that live555 has processed that message.  
  Therefore the VLC code should also have processed the 200 OK around this point in time, but this never happens (see client.VLC.log). Typically at some point VLC reports: 
  'E/VLC     (18053): [0x2dbda8]: live555 demux RTSP PLAY failed RTSP response was truncated. Increase "RTSPClient::responseBufferSize"'



- At line 17730 the ' RTCPInstance error: Hit limit when reading incoming packet over TCP. Increase "maxRTCPPacketSize"' message starts flooding the log file which eventually hangs VLC. 
  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, 
  which seems to indicate that if the live555 code has started processing RTP/RTCP over TCP data, the 200 OK is ignored somehow.


Any thoughts on this?
Please let me know If you want me to try out any fixes, add logging, etc.


Regards,
Ralf










-- 
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.

Please consider the environment before printing this email.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121016/f69224b1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logs.tar.gz
Type: application/octet-stream
Size: 201925 bytes
Desc: not available
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20121016/f69224b1/attachment-0001.obj>