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 315352 - pausing elements in a pipeline does not stop them
pausing elements in a pipeline does not stop them
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-09-06 13:08 UTC by Stefan Sauer (gstreamer, gtkdoc dev)
Modified: 2005-11-14 15:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
example that tests state changes (4.49 KB, text/plain)
2005-09-06 13:10 UTC, Stefan Sauer (gstreamer, gtkdoc dev)
Details
example that tests state changes (5.14 KB, text/plain)
2005-09-06 13:40 UTC, Stefan Sauer (gstreamer, gtkdoc dev)
Details

Description Stefan Sauer (gstreamer, gtkdoc dev) 2005-09-06 13:08:14 UTC
see attached example
Comment 1 Stefan Sauer (gstreamer, gtkdoc dev) 2005-09-06 13:10:47 UTC
Created attachment 51865 [details]
example that tests state changes

when pausing element the sound continues to play and the streamtime of the
element continiues too. That sound like a good indication that the elements
have not been paused.
Comment 2 Stefan Sauer (gstreamer, gtkdoc dev) 2005-09-06 13:40:08 UTC
Created attachment 51871 [details]
example that tests state changes

example now also check states after setting them
Comment 3 Wim Taymans 2005-09-15 14:21:10 UTC
in 0.9 there is no difference in PAUSE and PLAYING, only for sinks that don't
render buffers in PAUSED. For all other elements it is exactly the same.
Comment 4 Stefan Sauer (gstreamer, gtkdoc dev) 2005-09-20 13:31:03 UTC
what is the difficulty in not pulling data from pads, where the element is paused?
Comment 5 Andy Wingo 2005-10-06 10:20:05 UTC
Dataflow starts in the ready->paused transition. It is normal to see dataflow
happening in any of these states. However the sink should block when it actually
gets a buffer when it is in PAUSED. Why wouldn't you want dataflow in paused, if
it is never output (as in with audio pipelines)? And if you really don't,
consider not starting tasks in ready->paused (e.g. via using live sources).

Or am I misunderstanding?
Comment 6 Stefan Sauer (gstreamer, gtkdoc dev) 2005-10-06 17:14:41 UTC
@andy: my problem is that a buzztard song can have *lots* of elements. As a
musican there are three states (except normal) of gear you want to use:
* mute:
means don't pull data from this elements anymore or alternatively switch to a
silence element on-the-fly. the question here is, can I unlink the pads and
connect the peer of the element to be muted to a silence element while the
pipeline is in playing
* solo:
mute everything but this element
* bypass:
only interesting for effects. same questing - can I link elements src to dst
on-the-fly
Comment 7 Andy Wingo 2005-11-14 14:13:26 UTC
You can link on the fly, yes. But normally mute/solo don't affect e.g. processor
usage -- instead of outputting data on certain pads it just outputs 0. You
should have different means for setting those states. IMO anyway. I don't think
your question relates much to GStreamer states.
Comment 8 Stefan Sauer (gstreamer, gtkdoc dev) 2005-11-14 15:03:30 UTC
I not implement the desired behavior, be changing the pipeline. e.g. for mute I
swap the element with a "audiotestsrc wave=silence".