If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
http://bugzilla.gnome.org/show_bug.cgi?id=437652
GStreamer | gst-plugins | Ver: 0.10.12
Tim-Philipp Müller changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |DUPLICATE
Summary|Playbin Element Blocks GUI |GStreamer network elements
|and MainLoop |block in state change
| |function
Target Milestone|HEAD |NONE
------- Comment #3 from Tim-Philipp Müller 2007-09-08 21:06 UTC -------
It's really a general problem with most of our networking elements I'm afraid
(also those not using gnomevfssrc). There's unlikely to be a quick fix for
this. Even if we didn't block on the upwards state change by putting the
blocking stuff into the streaming thread, you'd still have the problem that
shutting down the pipeline (e.g. when the user clicks 'next') will block until
the blocking call in the streaming thread has finished.
Also see bug #403122 for the mmssrc case.
gnomevfssrc is unlikely to get fixed at this point, but there's going to be a
new gvfssrc at some point when the new GVFS lands in GLib.
Marking as duplicate of #338827 for now, since that's the most important
networking element besides mmssrc and there's a different bug for mmsssrc
*** This bug has been marked as a duplicate of 338827 ***
--
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.
You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=437652.