Hi Ross, I have some more information, hopefully somewhat helpful in tracking down the problem. I discussed the issue with my colleagues and have now found out that they are also *not* able to receive the stream using the latest version of VLC compiled with live555 2012.10.04.
However, using an older build of VLC Android with the live555 2012.10.04 yields *very* good results i.e. a very low failure rate to starting the stream. It even works most of the time over Edge connections. The fixes you've made are most apparent here and have made a *huge* improvement in terms of connectivity. > OK, your log suggests that 'incomplete' data is being received over TCP (by > the client), which implies (assuming that your client+server OS's TCP/IP > implementation is correct) that some of the server's writes to the TCP socket > are failing. The fact that this is happening would seem to indicate it. The thing is though, that a) we have increased the server's TCP send buffers to compensate for a start-up delay and b) we do live rate adaptation according to the bandwidth of the users. c) In the case where we can not adapt the bandwidth to the client's needs, we kick the client from the server. The problem is that the stream never even starts to play. Also, it cannot be a network bandwidth issue since the older version of the app *is* consistently able to stream the media using the same device and same Internet connection. What also doesn't quite add up to me is that VLC reports the Play response as failed: I've attached a recent log I got using the latest VLC live555 combination. Right at the end of the log, one can see that the PLAY request failed, again with the "response buffer truncated" message. This seems to indicate that something has gone wrong during the RTSP exchange. Correct me if I'm wrong, but if it were a TCP send buffer issue, I would first expect the PLAY request to succeed, and then during the PLAY phase first the receiver buffer on the client would fill up, and then the Send buffer on the server and then finally it would fail. I would expect the 200 OK to have been received and processed by the client way before that happens? Further information: this is one of two scenarios that seem to occur on startup. In the other scneario the RTCP handler is called to handle the RTP data until the RTCP buffer fills up (log attached to previous post). Ross, I really don't mean to harp on this issue, but this is currently a show-stopper for us. Any advice would be appreciated. Again, if there is any debug logging you can think of that I can add to the live555 build on Android I'd be glad to add it and report back. 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.
live_log.tar.gz
Description: Binary data
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
