After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 120046 - Run the pipeline in its own thread.
Run the pipeline in its own thread.
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-editor
git master
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 120047 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-08-17 03:05 UTC by ramon
Modified: 2006-03-29 16:10 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description ramon 2003-08-17 03:05:46 UTC 
Currently, gst-editor blocks if any element of the pipeline does a blocking
operation. Unfortunately, this cannot be workarounded by placing the
blocking elements in its own thread bin.

Please run the user interface and the pipeline in a different thread.
Comment 1 David Schleef 2003-08-17 05:16:07 UTC 
*** Bug 120047 has been marked as a duplicate of this bug. ***
Comment 2 ramon 2003-08-18 10:14:16 UTC 
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.
Comment 3 Andy Wingo 2005-07-14 15:54:59 UTC 
This will be fixed when gst-editor is ported to GStreamer 0.9.
Comment 4 Wim Taymans 2006-03-29 16:10:25 UTC 
closing, this is irrelevant and automatic when porting to 0.10 happens. No need to keep this bug around.