<HTML>
<HEAD>
<TITLE>Re: Receiving in multiple threads </TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Apologies, Ignore point 3, I found the necessary call in MediaSubsession (setClientPortNum). I have been working mainly in the server domain, and this is my first real play with the Client side code.<BR>
<BR>
Comments on the rest of the email are still requested tho.<BR>
<BR>
Stuart<BR>
<BR>
On 3/7/09 5:21 PM, "Rawling, Stuart" <<a href="SRawling@pelco.com">SRawling@pelco.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Hi Guys,<BR>
<BR>
I have an application that uses the RTSPServer code to send streams out to clients. The source of what it sends varies and is pluggable. All of these plugins end up writing to a unix pipe, which the RTSPServer code reads and streams out. Even tho the app and the plugins are multi threaded, I have taken great care to protect the integrity and single threaded nature of the live555 event loop. And it works very well.<BR>
<BR>
However, I am integrating with some new plugins that are also using live555 (they are restreaming existing rtsp streams) and I am seeing some strange behaviours. First of all sometimes I see the wrong video coming in the wrong pipe. I believe the cause of this is because although the plugins have been written to instantiate their own usageenvironement and taskscheduler, they are all using RTSP client. I am theorizing that in some circumstances, such as connecting to another RTSP server of the same type, they are actually initiating streams being sent to the same port, and the 2 instances of the live555 event loops are competing over the incoming packets. Streaming a single source is fine, and mixing other streams from plugins not based on live555 is fine too.<BR>
<BR>
To address this I am looking at making these plugins share the same usageenvironment and event loop. <BR>
<BR>
Can you comment on 3 things:<BR>
<BR>
</SPAN></FONT><OL><LI><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>My understanding is that so long as each instance of the library uses its own usageenvironment and event loop, it is ok to have multiple instances in multiple threads (although I agree this is really not advised).
</SPAN></FONT><LI><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>My hypothesis about the RTSPClient initiating streams from similar sources that stream to similar port numbers could be the cause of the above issue, and my proposal would make sense.
</SPAN></FONT><LI><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Would it make sense to add an optional base port for the client to use, similar to RTSPServer?<BR>
</SPAN></FONT></OL><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
<BR>
Thanks for any help provided.<BR>
<BR>
Stuart<BR>
</SPAN></FONT></BLOCKQUOTE>
<BR>
- ------------------------------------------------------------------------------<BR>
Confidentiality Notice: The information contained in this transmission is legally privileged and confidential, intended only for the use of the individual(s) or entities named above. This email and any files transmitted with it are the property of Pelco. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you receive this communication in error, please notify us immediately by telephone call to +1-559-292-1981 or forward the e-mail to administrator@pelco.com and then permanently delete the e-mail and destroy all soft and hard copies of the message and any attachments. Thank you for your cooperation. <BR>
- ------------------------------------------------------------------------------<BR>
</BODY>
</HTML>