> On Nov 12, 2014, at 12:31 PM, Ross Finlayson <finlay...@live555.com> wrote: > >> I’ve got this working along the lines you’ve described, but the problem I’m >> running into is a need for some kind of external (to live555 thread) >> reference to each RTSPClient, in order to trigger other events (stopping >> one, for example). That’s why I thought about creating the clients outside >> of the loop, but I can understand why that’s not a good idea. Creating the >> RTSPClient instance inside the eventTrigger handler doesn’t provide a way to >> pass a reference back, either (as far as I can tell). >> >> Do you have any recommendation on how to give the main application thread a >> useful reference to each stream for use with later event triggers? It seems >> to me that this would be a common desire for an app that handles multiple >> streams. > > I suggest creating - in the external thread - some object (struct) that > represents the stream. This struct could contain some fields (such as the > RTSP URL) that would be set by the external thread, and other > LIVE555-specific fields (such as a pointer to a “RTSPClient” object) that > would be set and accessed only by the LIVE555-event-loop thread. > > Then, pass a pointer to this struct (rather than just the RTSP URL) as the > ‘clientData’ parameter to “triggerEvent()”.
OK, so the “addNewStream” triggered event, where the RTSPClient is created, would add the pointer to it then. I’m a bit concerned about thread-safety here, since the struct is created on the GUI thread, then manipulated on the live555 thread. I suppose you’re implying that safety would come from being careful about each field only being set from the appropriate thread. -e
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
