[Gstreamer-bugs] [Bug 120046] Changed - Run the pipeline in its own thread.

[bugzilla-daemon at widget.gnome.org]

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.
+
+