On Thu, Nov 24, 2011 at 1:25 PM, Ross Finlayson <finlay...@live555.com>wrote:
> Receiving RTP over TCP in current releases with multiple sub-sessions is, > by and large, broken as best I can tell due to something with the new > synchronous API > > > You mean "asynchronous API". > > We talked about your problem a lot on the mailing list back in July. As > far as I can tell, you're the only person having this problem with > receiving RTP-over-TCP, so it may be inaccurate to describe it as being > "broken". (I also doubt that the asynchronous API is responsible.) Back > in July I wasn't able to explain the symptoms that you were seeing, but I > still suspect that you might be using multiple threads incorrectly (by, > perhaps inadvertently, accessing the same LIVE555 object(s) from multiple > threads). If you stop using multiple threads (as I've noted several times, > you don't need multiple threads to concurrently receive multiple RTSP/RTP > streams within a single LIVE555 application if you use the asynchronous > API), then I suspect your problems will go away. > > Yes, I meant asynchronous. My apologies. I am not using multiple threads; I've been using this library for almost four years, so I'm well aware of the threading implications. Every Live555 instance I work with is completely contained on a single thread, and the only signaling that occurs is through watch variables. Also, I could easily see someone missing this issue because in the currently library the behavior is masked. You still get marginal performance due to the workaround that was included in the library. But I can still reproduce the issue on demand, and I suspect other people A) aren't using TCP with multiple subsessions or B) aren't looking closely.
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
