On Tue, 2007-05-08 at 11:19 +0200, Benjamin Otte wrote: > (short reply here, so you can continue your interesting discussion, > I'll answer in more detail when I'm back from UDS) > > On 5/8/07, Alexander Larsson <[EMAIL PROTECTED]> wrote: > > On Tue, 2007-05-08 at 03:33 -0500, Hans Petter Jansson wrote: > > > > I know Benjamin mentioned multiple contexts was needed for gstreamer > > integration. It would be nice to hear some details about this > > > GStreamer runs the pipeline in seperate threads. While reads are > typically scheduled from just one thread, any thread could potentially > initiate actions on the stream. An example would be seeking: seek > events are dispatched from the thread doing the seek - this could be > the main thread for a user event or any other thread if a downstream > element needs to seek. So the event would cancel the read operation > and do the seek. This would wake up the read thread noticing it was > interrupted and reschedule the read.
So, you would have one of gstreamers threads doing the read operation, and this would be using async i/o and a custom glib mainloop on that thread. Then say the main thread on user input decides to seek in the stream, this seek call on the main thread will cancel the async read operation running in the gstreamer thread and schedule a new seek operation there instead. Is this a correct example? I'm still not sure why gstreamer needs to run its own mainloop in its thread though. If its async, then it should be able to use the default mainloop. Is it because there is no guarantee of the default mainloop running always? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc [EMAIL PROTECTED] [EMAIL PROTECTED] He's a short-sighted guitar-strumming assassin in drag. She's a foxy insomniac detective with a knack for trouble. They fight crime! _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list