[Live-devel] Problems with RTSPClient, CSeq variable and SANYO network cameras ...

[Matt Schuckmann]

On 4/1/2010 7:06 PM, Ross Finlayson wrote:
>> 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.
Ross, Actually your FAQ says
"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). "

I have done this and so far it has worked fine, I haven't noticed if 
this particular problem has cropped up, but maybe LiveMedia RTSPserver  
is more forgiving. I can't say if the original poster did the same. From 
the sounds of it even if they did they'd have this problem. Is there any 
reason why that variable is a static?

I can think of many cases where one may not have control over running 
all instances of RTSPClient in the same thread. One example is in a 
plug-in type environment. In one of my cases I've embedded RTSPClient in 
an ActiveX control and users of my control could run multiple instances 
of the control in their application or web page and I have no control 
over it. I've followed your FAQ and created an independent thread for 
each RTSPClient and in each case created it's own UsageEnvironment and 
TaskScheduler. I have been very careful to use thread safe mechanisms 
(not global's which are not thread safe) for cross thread communication. 
Are you now telling me that I shouldn't follow your FAQ? If this is the 
case can we please fix it?

I personally find your disdain for threads antiquated and naive, I find 
a well thought out multi-threaded application easier to code, 
understand, debug, extensible, and with today's OS's and processors much 
more per-formant. Of course that's just my opinion and it's not to say 
that there is anything wrong with the way LiveMedia is implemented. I 
very much appreciate LiveMedia and the work you've done.

Matt S.

BTW Have you ever encountered anyone that has ever successfully 
implemented a TaskScheduler that was multi-threaded?  I glanced at it 
once or twice but it didn't seem very straight forward and so wasn't 
worth it at the time.