GNOME Bugzilla – Bug 328520
GstAdder gets 'stuck' when one source reaches EOS
Last modified: 2006-08-20 13:09:48 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.
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?
this should be fixed now with latest adder changes.
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.