Hi Jeremy & Ross, FWIW: Re-reading the posts from July i *might* have something to add to the discussion. We exclusively use the RTP over TCP option and also saw a strange issue with it fairly recently. Just recapping in case it is of use to either of you:
We compiled the Android version of VLC and made some changes to be able to stream over the network using RTP over RTSP. When switching from wireless to 3G/Edge the stream would fail to play. At the time I thought it might have something to do with RTP being in the same packet as the RTSP (see http://lists.live555.com/pipermail/live-devel/2011-October/013866.html) but Ross corrected this line of thought in his response and further testing confirmed that. Further debugging shows that when things went wrong, the stream channel ID could not be matched on the client correctly: IIRC the server (also running live555) was sending video and audio using IDs 2 and 3, and the client was trying to match 0 and 1. Also, IIRC, the latest live555 code in the client (obtained when building the android version) does a check and goes back into a searching for $ state if it fails to match the ID. Older code didn't have this check. It looked like mismatching the IDs had broken the state machine on the client. At this stage I was clueless how to proceed (esp. since this failure to match IDs only happened over 3G and *not* over wireless). I then updated our server application to use the latest version of live555 and the problem went away completely. So to conclude: somehow using a new version of the RTSP client (with async interface) over 3G/Edge with an older version of the live555 server caused a mismatch in stream channel IDs. @Jeremy: I hope this helps. In your case, is the server also running live555 and are you able to try to upgrade the server? _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
