[Live-devel] Live 555 multi-thread support
Jerry Johns
Jerry.Johns at nuvation.com
Thu Jul 9 07:54:16 PDT 2009
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: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] 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: live-devel-bounces at ns.live555.com
[mailto:live-devel-bounces at ns.live555.com] 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20090709/0d9b012c/attachment.html>
More information about the live-devel
mailing list