[Gstreamer-bugs] [Bug 120046] Changed - Run the pipeline in its own thread.
bugzilla-daemon at widget.gnome.org
bugzilla-daemon at widget.gnome.org
Mon Aug 18 03:14:17 PDT 2003
Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.
http://bugzilla.gnome.org/show_bug.cgi?id=120046
Changed by ramon at jl1.quim.ucm.es.
--- shadow/120046 Sun Aug 17 01:16:08 2003
+++ shadow/120046.tmp.26047 Mon Aug 18 06:14:17 2003
@@ -20,6 +20,36 @@
blocking elements in its own thread bin.
Please run the user interface and the pipeline in a different thread.
------- Additional Comments From ds at schleef.org 2003-08-17 01:16 -------
*** Bug 120047 has been marked as a duplicate of this bug. ***
+
+------- Additional Comments From ramon at jl1.quim.ucm.es 2003-08-18 06:14 -------
+Well, the problem is not well explained in this bug.
+
+I placed in gst-editor a pipeline with a dedicated thread. After I
+issued the command "Play", the editor was still responsive. But, when
+in the playing state, I issued the command "Stop", then the editor
+froze completely.
+
+I tested several pipelines, like:
+
+{ udpsrc ! queue } ! fakesink
+
+{ udpsrc | fakesink }
+
+This report is in part wrong. I assumed that a state change takes
+place in the thread context of the application, and so even if the
+plugin is blocked it happens if the app is in a different thread.
+But experimenting with gst-launch (because it is easier to hack, see
+bug #120065), this seems to be wrong. State change events cannot
+arrive to a blocked element, even if the element has a dedicated
+thread. The code of gst_thread_change_state issues a call to
+gst_threaded_catch, and thus blocks until the thread is in the main
+event loop.
+
+Thus applying the suggestion of this bug would solve only part of the
+problem. The user interface would not freeze when a blocking plugin is
+used, but Gstreamer would still freeze. Thus, I am opening a new bug.
+
+
More information about the Gstreamer-bugs
mailing list