[gst-devel] GStreamer in double loop

Jeffrey Barish jeff_barish at earthlink.net
Thu Jun 18 18:21:33 CEST 2009


GStreamer requires gobject.  gobject runs in a loop, normally by calling the
run method on the main loop.  That loop blocks until there is something to
do.  I also need to monitor sockets over which I send commands about what
GStreamer is supposed to do.  Normally, it runs in a loop that blocks until
a command arrives on a socket.  It is not possible to run both of these
loops in the same thread using the normal procedure because they both
block.  One possibility is to perform the looping manually.  gobject has a
method that makes it possible to perform an iteration of the context.  I
could check the sockets and then perform an iteration that blocks.  I would
repeat those two steps every time a message arrives from gobject.  But
there are long periods when no messages arrive, so I could be missing
commands that have arrived on a socket while I am waiting for a GStreamer
message.  If I make the iteration nonblocking, then the loop will buzz too
quickly and the CPU load will go to 100%.  If I put in a sleep, I can get
the CPU load under control, but then I will be missing both GStreamer
messages and socket commands while sleeping.  If I block on the socket
access, I could be tardy in responding to GStreamer messages.  So this
approach doesn't work.

The only possibility, I believe, is to use multithreading.  The socket
polling goes in one thread and the gobject loop goes in another.  Both
threads send commands to playbin2 through a thread-safe queue.  A third
thread gets from the queue and blocks whenever nothing is there.  With this
approach, the moment a message arrives from gobject or a command arrives
from a socket, the appropriate command is put in the queue and the thread
reading the queue wakes to execute it.  Response time should be low in both
cases.

I have implemented this solution.  It works fine on the socket side. 
However, whenever I use the run method of the GObject maincontext, the
program hangs.  If I run the GObject loop using the manual method and stick
in a 1-second sleep, it works fine, so I know that I have the queue and
related code working correctly.  However, I cannot use the manual solution
because the response time could be too high because of the sleep.  I am
stymied by the GObject problem.  I should perhaps post a message to the gtk
mailing list, but I was wondering whether any other GStreamer users have
ever encountered a problem that required fast response to two loops and
what solutions you might have found.  If anyone knows multithreading,
perhaps you could suggest things that might cause the GObject loop to hang.
-- 
Jeffrey Barish





More information about the gstreamer-devel mailing list