> > 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. >> It's because CSeq number is a static variable in RTSPClient. >> > > 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)?) > > Instead, you should be using a single event loop (in a single thread) - > even to make multiple RTSP client requests. > -- > > From the faq,
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). 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: Does LiveMedia library conform to RTSP standard in this matter or maybe it is a bug in Sanyo devices ? 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: 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. 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?
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
