[gst-devel] gst_collect_pads_available bug?

Michael Horbovetz (horb) horb at cisco.com
Wed Apr 25 22:57:40 CEST 2007

is there a bug with gst_collect_pads_available?  the debug output below
shows that there are 2 pads with bytes to be read.  the documentation
for gst_collect_pads_available states that it returnes the maximum
number of bytes queued on ALL pads.  the last debug output shows that
gst_collect_pads_available returned 191 when it should have returned
382.  the code is below also.

gstreamer debug output:

DEBUG (0x9f20988 - 0:00:01.151182000) 
collectpads(  454)
gstcollectpads.c(849):gst_collect_pads_check_collected: All
active pads (2 + 0 >= 2) have data, calling gst_fakeadder_collected
DEBUG (0x9f20988 - 0:00:01.151255000) 
collectpads(  454)
gstcollectpads.c(662):gst_collect_pads_available: pad
0x9f20de8 has 191 bytes left
DEBUG (0x9f20988 - 0:00:01.151331000) 
collectpads(  454)
gstcollectpads.c(662):gst_collect_pads_available: pad
0x9f208e8 has 191 bytes left
LOG   (0x9f20988 - 0:00:01.151409000) 
fakeadder(  454)
gstfakeadder.c(347):gst_fakeadder_collected:<adder> starting
to cycle through channels, 191 bytes available


  /* get available bytes for reading, this can be 0 which could mean
   * empty buffers or EOS, which we will catch when we loop over the
   * pads. */
  size = gst_collect_pads_available (pads);

  GST_LOG_OBJECT (fakeadder,
      "starting to cycle through channels, %d bytes available", size);


More information about the gstreamer-devel mailing list