GNOME Bugzilla – Bug 763770
multiqueue: not-linked pads might not drain out at EOS
Last modified: 2016-07-01 09:06:47 UTC
commit #c3454a85 in core introduced a regression to multiqueue EOS handling when not-linked pads are present. commit c3454a85c5207dfe33dcaaebf37d8163198a6816 Author: Mark Nauwelaerts <mnauw@users.sourceforge.net> Date: Sat Feb 21 17:13:26 2015 +0100 multiqueue: avoid returning downstream GST_FLOW_EOS from previous segment to current upstream segment The problem is that the not-linked pad output is throttled based on linked pads, with some logic to ignore EOS pads. The commit changed the stored srcresult which used to record that the last push result was GST_FLOW_EOS, and now it's possible that not-linked streams are not drained out. Any data which is pushed after all linked streams have gone EOS will stall in the multiqueue and never drain. Unit test and patch coming.
Created attachment 324122 [details] [review] tests: Check multiqueue not-linked EOS handling Add a test which checks that not-linked pads continue to output data after linked pads have gone EOS
Created attachment 324195 [details] [review] tests: Check multiqueue not-linked EOS handling Add a test which checks that not-linked pads continue to output data after linked pads have gone EOS
Created attachment 324196 [details] [review] multiqueue: Fix not-linked pad handling at EOS Ensure that not-linked pads will drain out at EOS by correctly detecting the EOS condition based on the EOS pad flag (which indicates we actually pushed an EOS), and make sure that not-linked pads are woken when doing EOS processing on linked pads.
I have an issue caused by this same patch but it seems this fix doesn't help me. Will keep digging to understand exactly what is happening. (Not that this patch isn't useful, just my issue is different)
(In reply to Thiago Sousa Santos from comment #4) > I have an issue caused by this same patch but it seems this fix doesn't help > me. Will keep digging to understand exactly what is happening. > > (Not that this patch isn't useful, just my issue is different) What symptoms are you seeing?
I am reasonably sure that this patch a) only has any effect at EOS b) only on not-linked pads c) the current behaviour is definitely broken. I think it should go into 1.8.0, so I'm going to commit it and get as much testing as possible (and probe it every way I can over the weekend). We can always revert if a problem shows up.
Created attachment 330701 [details] [review] multiqueue: Fix behaviour with not-linked and eos pads This is an update on c9b6848885f4675d447e823c8fb117e247658252 multiqueue: Fix not-linked pad handling at EOS While that commit did fix the behaviour if upstream sent a GST_EVENT_EOS, it would break the same issue when *downstream* returns GST_FLOW_EOS (which can happen for example when downstream decoders receive data from after the segment stop). GST_PAD_IS_EOS() is only TRUE when a GST_EVENT_EOS has flown through it and not when a GST_EVENT_EOS has gone through it. In order to handle both cases, also take into account the last flow return.
commit 530001661ddba6a0b1a7a07c9805688d83a05622 Author: Edward Hervey <edward@centricular.com> Date: Fri Jul 1 09:44:12 2016 +0200 multiqueue: Fix behaviour with not-linked and eos pads This is an update on c9b6848885f4675d447e823c8fb117e247658252 multiqueue: Fix not-linked pad handling at EOS While that commit did fix the behaviour if upstream sent a GST_EVENT_EOS, it would break the same issue when *downstream* returns GST_FLOW_EOS (which can happen for example when downstream decoders receive data from after the segment stop). GST_PAD_IS_EOS() is only TRUE when a GST_EVENT_EOS has flown through it and not when a GST_EVENT_EOS has gone through it. In order to handle both cases, also take into account the last flow return. https://bugzilla.gnome.org/show_bug.cgi?id=763770