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 335863 - collectpads loops when pads are blocked
collectpads loops when pads are blocked
Status: RESOLVED NOTABUG
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: 2006-03-24 17:04 UTC by Stefan Sauer (gstreamer, gtkdoc dev)
Modified: 2006-08-29 15:01 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
example showing the problem (6.93 KB, text/x-csrc)
2006-03-24 17:06 UTC, Stefan Sauer (gstreamer, gtkdoc dev) 		Details
another variant (7.03 KB, text/x-csrc)
2006-03-29 10:02 UTC, Stefan Sauer (gstreamer, gtkdoc dev) 		Details

Description Stefan Sauer (gstreamer, gtkdoc dev) 2006-03-24 17:04:50 UTC 
This appears in the log forever

DEBUG (0x80500a8 - 0:00:03.750757000)          collectpads(24354) gstcollectpads.c(644):gst_collect_pads_is_collected: All active pads (2) have data, calling gst_adder_collected
DEBUG (0x80500a8 - 0:00:03.750926000)          collectpads(24354) gstcollectpads.c(644):gst_collect_pads_is_collected: All active pads (2) have data, calling gst_adder_collected

There are two audiotestsrc elements connected to the adder. One has its pad blocked. Shoudn't collectpads check for blocked pads?
Comment 1 Stefan Sauer (gstreamer, gtkdoc dev) 2006-03-24 17:06:55 UTC 
Created attachment 61926 [details]
example showing the problem

run as:
GST_DEBUG="*:2,coll*:4" ./states1b

and wait a couple of second, until it blocks the src-pad of one sine-generator.
Comment 2 Stefan Sauer (gstreamer, gtkdoc dev) 2006-03-29 09:29:06 UTC 
to looping happens if I set the element with the blocked-pad to STATE_READY, if it is STATE_PAUSED the above does not happen. Still this blocks the whole pipeline. Adder (or more specifically CollectPads) does not ignore blocked-pads and thus blocks itself.
Comment 3 Stefan Sauer (gstreamer, gtkdoc dev) 2006-03-29 10:02:52 UTC 
Created attachment 62282 [details]
another variant

still not be able to silence one source and keep the pipeline running
Comment 4 Wim Taymans 2006-08-29 15:01:49 UTC 
Adder blocks as long as no data is received on all pads. Deliberatly blocking dataflow on one pad by using a pad block somewhere upstream is one way of not feeding data to adder. Adder can and should not check if some upstream element happens to be pad-blocked. If part of the upstream pipeline should not be mixed, the adder sinkpad should be released.