<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I've found out that when you run a few different instances of RTSP clients in separate threads CSeq number is not increased by one with each consecutive request.<br>
It's because CSeq number is a static variable in RTSPClient.<br>
</blockquote>
<br></div>
This is a perfect illustration of why you are not supposed to run LIVE555 library code in multiple threads. (Have you read the FAQ entry about threads? If not, then why not (because you were asked to read the FAQ before you subscribed/posted to the mailing list)?)<br>
<br>
Instead, you should be using a single event loop (in a single thread) - even to make multiple RTSP client requests.<br>
-- <br><font class="Apple-style-span" color="#888888"><br></font></blockquote><div>From the faq, </div><div><br></div></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;">
<div class="gmail_quote"><div><span class="Apple-style-span" style="font-family: 'Times New Roman'; font-size: medium; ">Another possible way to access the code from multiple threads is to have each thread use its own "UsageEnvironment" and "TaskScheduler" objects, and thus its own event loop. The objects created by each thread (i.e., using its own "UsageEnvironment") must not interact (except via global variables).</span> <br>
</div></div></blockquote><br><div>This is what I'm doing and haven't had a problem yet with our test servers. What I'm more interested in is from the original post:</div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;">
<div>Does LiveMedia library conform to RTSP standard in this matter or maybe it is a bug in Sanyo devices ?</div><div><br></div></blockquote>I would think that even in single-threaded usage, if multiple RTSP client requests are required, then the CSeq would still increase by more than one. Also from the original post:<blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;">
<div>SANYO network cameras end RTSP session with an error "Bad Request" when
the current request's CSeq number is greater then CSeq of the previous
one plus one.</div></blockquote><br><div>If this is expected behavior from the standard, I imagine I should make some changes before this actually becomes a problem... If this is a bug in the server implementation, I can make my bosses aware of it and try to steer away from such servers. Any advice?</div>