I forgot to add, but if you want to have multiple threads interact with LiveMedia, use pipes and shared fifo memory as your main base of data transfer/communication.
Pipes allow you to expose file handles that can then be 'listened' on by LiveMedia's task scheduler using the select() call - it will just add this file handle to its list of schedulable sleeping tasks, and once data gets transferred on that pipe, your function handler should awake. That combined with some sort of shared memory makes it a complete cinch to implement various packetizers. I usually have a base class that implements inter-thread data transfer, sub-classing DeviceSource - then I just latch on my packetizer classes on-top of this so that it becomes quite seamless. This way, you can have multiple streams, multiple codecs all implemented seamlessly as long as your base class does its job well of relaying data between threads. Key thing to note is not to use mutexes/conditional variables in the thread running LiveMedia, as then you might potentially be blocking the thread outside of the select() call - this incurs 'double' scheduling, and would prevent LiveMedia from servicing network events on time. Thanks, Jerry Johns Design Engineer Nuvation Research Corp - Canada Tel: (519) 746-2304 ext. 221 www.nuvation.com <http://www.nuvation.com/> ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Jerry Johns Sent: Wednesday, July 08, 2009 2:14 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Live 555 multi-thread support You don't really have to run it under multiple processes, especially since it works fine under its own thread (pthread in Linux) The heart of its implementation revolves around the select() call involving multiple sockets, so really, it is 'safe' as long as no one else uses those sockets/ports, and you don't try to run multiple instances of LiveMedia on multiple threads. I've successfully used LiveMedia in designs using this above concept and as long as you lower its thread priority relative to the other threads in your system, it chugs along just fine :-) Jerry Johns Design Engineer Nuvation Research Corp - Canada Tel: (519) 746-2304 ext. 221 www.nuvation.com <http://www.nuvation.com/> ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Ross Finlayson Sent: Sunday, July 05, 2009 5:58 AM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Live 555 multi-thread support Hi. I read the FAQ but I still not 100% sure about this: " Longer answer: More than one thread can still use this code, if only one thread runs the library code proper, and the other thread(s) communicate with the library only by setting global 'flag' variables. (For one possible use of this technique, see the answer to this question <http://www.live555.com/liveMedia/faq.html#exiting-event-loop> .) 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). " Is there any good guide-lines to run the Live555 (or OpenRTSP example) in multi-threaded fashion? Or my best bet would be to run separate processes? Yes, that's the best way - use multiple processes if you can. -- Ross Finlayson Live Networks, Inc. http://www.live555.com/
_______________________________________________ live-devel mailing list [email protected] http://lists.live555.com/mailman/listinfo/live-devel
