On Thu, Nov 24, 2011 at 1:25 PM, Ross Finlayson <span dir="ltr"><<a href="mailto:finlayson@live555.com">finlayson@live555.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div><blockquote type="cite"><div class="gmail_quote"><div><div>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</div>
</div></div></blockquote><div><br></div>You mean "asynchronous API".</div><div><br></div><div>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.</div>
<span class="HOEnZb"><font color="#888888"><br></font></span></div></blockquote><div> </div><div>Yes, I meant asynchronous.  My apologies.</div><div><br></div><div>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.</div>
<div> </div></div>