<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><blockquote type="cite"><div dir="ltr"><div><div><div><div><div><div>I am trying to use the openRTSP code in my program and use it to record from multiple sources at the same time. Therefore, I need to run each instance in a separate thread.</div></div></div></div></div></div></div></blockquote><div><br></div>No, the second sentence does not follow logically from the first. (See below.)</div><div><br></div><div><br><blockquote type="cite"><div dir="ltr"><div><div><div><div><div><div> But openRTSP code is not thread safe (many global variables). I will be left with three options:<br>
</div>1- To run openRTSP as a stand-alone process for each client stream.</div></div></div></div></div></div></blockquote><div><br></div>Yes, that is what you should do. E.g., use a shell script to exec multiple "openRTSP" commands concurrently.</div><div><br><blockquote type="cite"><div dir="ltr"><div><div><div><div><div>This would not be efficient, and I would lose control over each openRTSP running process. <br></div></div></div></div></div></div></blockquote><div><br></div>No, this would still be efficient, and you could easily control each "openRTSP" process, from your shell script. E.g., your shell script could note the pid of each "openRTSP" process, so it can kill them, if necessary.</div><div><br></div><div>I continue to be surprised how - in this century - so many programmers have become afraid of (or unaware of) structuring applications as multiple processes, resorting instead to using multiple threads within a single process - which is *much* more difficult, and *much* more error-prone (and is something that's required only when you need shared memory).</div><div><br></div><div><br><blockquote type="cite"><div dir="ltr"><div><div><div><div>2- To re-implement openRTSP with a same scheme as in testRTSPClient test program. Creating my own StreamClientState, ourRTSPClient and DummySink classes. But I would lose all the functionality implemented in openRTSP. Implementing every one of them would be hard.<br></div></div></div></div></div></blockquote><div><br></div>You wouldn't need 'all' the functionality of "openRTSP" - just the parts that you want. But in any case, I don't recommend that you do this, unless you need only very basic functionality of "openRTSP". (Especially as this is a hobby for you.)</div><div><br></div><div><br><blockquote type="cite"><div dir="ltr"><div><div><div><div>
</div>3- Try to make the current openRTSP implementation thread-safe, by defining StreamClientState and putting all global variables in playcomm.cpp in that class and trying to over ride RTSPClient used there. But the RTSPClient is initiated in the HandlerServerForREGISTERCommand and finding the correspondences is a bit hard.<br></div></div></div></div></blockquote><div><br></div>No, I don't recommend that you do this. The "openRTSP" code is very complex (in part because it's also used for "playSIP" - a SIP client). It's not something to mess with.</div><br><br><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px;"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">Ross Finlayson<br>Live Networks, Inc.<br><a href="http://www.live555.com/">http://www.live555.com/</a></span></span>
</div>
<br></body></html>