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 328520 - GstAdder gets 'stuck' when one source reaches EOS
GstAdder gets 'stuck' when one source reaches EOS
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
0.10.2
Other Linux
: Normal normal
: 0.10.7
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-01-25 05:43 UTC by Chong Kai Xiong
Modified: 2006-08-20 13:09 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Chong Kai Xiong 2006-01-25 05:43:37 UTC
Problem Description:

GstAdder gets caught in a do-nothing loop when one of its sources reaches EOS. 

When a sink pad reaches EOS, gst_collect_pads_is_collected() is called by gst_collect_pads_event(). If there are still sources active, the function then goes into a loop calling gst_adder_collected() until there is no more queued data.

The problem is, gst_adder_collected() uses gst_collect_pads_available() to determine the amount of data queued and returns immediately without doing anything if it is zero. But gst_collect_pads_available() returns 0 if any of the pads is at EOS regardless of whether there is any data queued on other active pads, so no queued buffers are dequeued and the abovementioned loop continues indefinitely. 

All this while, the lock on GstAdder's GstCollectPads structure is also held, making it impossible to perform actions such as removing a collected pad from another thread.


Proposed solution:

gst_collect_pads_available() should ignore EOS'ed pads and return the minimum amount of bytes queued on active pads. gst_adder_collected() should also ignore pads without a buffer queued.

Perhaps it would be useful to add a new function called gst_collect_pads_for_each_pad() that iterates through every pad in the same state e.g. active with buffers queued, active but no buffers queued, EOS, etc.
Comment 1 Wim Taymans 2006-03-23 10:22:51 UTC
someone needs to write down some use cases for adder, then figure out a plan to implement the required features correctly. Many people bump into the same issues you outlined. 

Someone willing to propose something? 
Comment 2 Wim Taymans 2006-05-15 16:21:19 UTC
this should be fixed now with latest adder changes.
Comment 3 Chong Kai Xiong 2006-08-20 13:09:48 UTC
Writing in just to confirm that it is fixed for me.

Additionally, the creation of a separate lock for the pad list also solved another problem I encountered but didn't file - that is, elements like audiotestsrc generated data so fast that it took a long time to lock GstCollectPads for adding new pads.