GNOME Bugzilla – Bug 721395
GstCollectPads-related freeze in pads mgmt
Last modified: 2018-05-04 13:06:55 UTC
The problem i experience can be reproduced with my GstTq sketch: https://github.com/krieger-od/gst_tq , if you change line 14 to "gboolean release_sinkpads = FALSE;". So we have such a pipeline: http://whdd.org/bin.png It is in playing state. Then we want to release both tq srcpads, which are linked with mpegtsmux element. It works when we release also muxer sinkpads in order. But it freezes the app if we don't release muxer sinkpads immediately. This can happen, for example, if we want to connect them with something else. Actual data on the testcase, and some more explanation can be found here: http://lists.freedesktop.org/archives/gstreamer-devel/2014-January/045348.html The explanation of GstTq concept can be found here: http://lists.freedesktop.org/archives/gstreamer-devel/2014-January/045346.html
Found workaround: sending EOS event to just-detached muxer's sinkpad avoids deadlock.
(In reply to comment #1) > Found workaround: sending EOS event to just-detached muxer's sinkpad avoids > deadlock. I am not sure about reasons, but sometimes this doesn't work either. More safe approach is to save requested sourcepads into some container, then set sink element (to which these requested sourcepads are connected to) to NULL state, then release requested sourcepads through BLOCKING pad callback.
Muxers usually use GstCollectPads to manage their pads. GstCollectPads waits for buffers on all pads to be able to compare the timestamps available and deliver the buffers in timestamp order. So simply unlinking/removing a pad that was pushing to the muxer will make GstCollectPads block waiting for data on that pad. If you: a) Remove the sinkpad: it should work as collect pads should not consider that pad anymore and will continue operating. If this doesn't work, there might be a bug. b) Don't remove: collect pads will keep waiting for buffers on that pad and the muxer will stall c) Don't remove and link something else: In theory it should work, but then how does the new timestamps compare to the ones from the previous input? I wouldn't recommend this unless you know what you are doing. It seems that your test app has a flag for doing either 'a' or 'b', and the results seem to be correct? You also mention that you are trying to do 'c', what is the use case?
(In reply to comment #3) > b) Don't remove: collect pads will keep waiting for buffers on that pad and the > muxer will stall > > It seems that your test app has a flag for doing either 'a' or 'b', and the > results seem to be correct? Right, except that in case "b" application is just unable to operate on srcpads (linked to muxer sinkpads) due to deadlock. Muxer stalling itself is not an issue here, but pipeline operation is.
collectpads is effectively deprecated in favour of GstAggregator and unlikely that anybody is going to work on anything in collectpads at this point. Muxers should be moved to aggregator if needed, and such problems likely don't exist there due to completely different thread management.