GNOME Bugzilla – Bug 738931
decodebin2: Group never exposed with some GAP'ed streams
Last modified: 2018-05-04 12:35:36 UTC
This issue happens with demuxers (such as tsdemux master) that expose streams that might not have data on it straight away (or ever for that matter) and which use parsers. The example can be seen with ac3 streams, which will connect to ac3parse and linking/auto-plugging of a potential decoder is delayed until ac3parse get enough data to figure out fixed caps. Meanwhile the other streams (say h264) will be moving on forward, eventually overrunning multiqueue, which will try to expose the group ... but it can't since one of the chains (to which ac3parse belongs) will never complete, and therefore the whole group will never complete => decodebin just sits there. Some options: * When multiqueue overruns, remove any streams with parsers that haven't fixated yet. ** Cons: If data arrives later on the ac3 stream ... it won't be decoded/exposed. * Disable delayed linking of parsers ** Cons: Might end up picking up the wrong decoder Any other option ?
I forgot to mention that those streams *do* have GAP events sent at regular intervals, so we do know that the streams are moving forward (albeit without data), as opposed to bad/huge upstream interleaving.
Created attachment 289129 [details] [review] decodebin: Handle streams that don't complete fast enough When multiqueue overrun's, we mark all streams that haven't completed as: 1) a deadend, since we don't expect auto-plugging to complete there 2) drained, since EOS will have no impact on the stream
This is a tentative patch of the first solution
Comment on attachment 289129 [details] [review] decodebin: Handle streams that don't complete fast enough This patch is actually quite racy. We might very well have a multiplex that pushes a lot of buffers on one stream (say video) before pushing on the other stream (say audio). We'd get blocked on the video stream, multiqueue would overrun ... but we'd still be in the process of identifying what's going on on the other stream :(
Created attachment 300112 [details] decodebin never be exposed level5 full log I met a same issue with sparse audio mkv stream. The content has three streams, one video and two audio. The second audio stream is sparse stream and it has empty stream at the beginning of the contents. So, mkv demuxer created all of its srcpad, and emit no-more-pads signal. But the group never be exposed due to one of the chain(sparse audio) will never complete. I attach related log at first.
Here is an MPEG-TS stream that prerolls and plays fine in 1.4 but not in master: http://absolut.zogzog.org/goinfre/share/samples/ts/11_Stereo_MPA_H264HD_IRDCert_RevB.m2ts Reverting b59a9262c069d8f0 (tsdemux: GAP detection) fixes the issue.
IMHO disabling delayed linking of parsers when the multiqueue overruns is a better solution than just disabling the faulty stream. At least it gives a chance to the delayed stream to be played.
This issue could also be avoided in some cases, since decodebin lowers the multiqueue limits on no-more-pads, while preroll might not be complete yet. So in the tsdemux master case, lowering the multiqueue limits later could help.
Dropping this. Fixed trivially in playbin3/decodebin3.