GNOME Bugzilla – Bug 497002
Decodebin2 deadlock when demuxer bufferallocs on exposed raw pad
Last modified: 2012-06-28 09:20:16 UTC
I have a case where * demuxer exposes (first) raw pad inside decodebin2 * decodebin2 plugs multiqueue to the raw pad * decodebin2 exposes multiqueue src pad and sets it blocked * demuxer prepares to push first buffer and calls gst_pad_alloc_buffer * multiqueue bufferalloc function is called -> deadlock, bufferalloc blocks because multiqueue src pad is blocked and demuxer can't go on Should the first buffers be allocated by multiqueue in case the src pad is blocked?
tricky one. I'm not feeling comfortable about constantly checking whether source pads are blocked...
You can't check reliably anyway - not atomically. I think the correct fix will involve having decodebin track pads which come directly from the demuxer via multiqueue - the should be handled differently to pads that are buffer-alloc'd through a decoder. I suppose it is possible to have a buffer-alloc on a decodebin2 output pad from a decoder which is proxying an upstream buffer-alloc request, but I can't think of any instances where that is implemented, and I don't know how we would handle it.
I don't really see the deadlock here. After decodebin2 exposed the pads it'll unblock the pads and dataflow can continue. Am I missing something?
As I understand it, the deadlock happens when you ask decodebin2 to give you 'encoded' formats, direct from the demuxer - ie, the demuxer is trying to buffer-alloc one the first pad, so it gets blocked while decodebin2 waits for the other pads, which will never come because the demuxer is blocked and can't create them.
(In reply to comment #4) > As I understand it, the deadlock happens when you ask decodebin2 to give you > 'encoded' formats, direct from the demuxer - ie, the demuxer is trying to > buffer-alloc one the first pad, so it gets blocked while decodebin2 waits for > the other pads, which will never come because the demuxer is blocked and can't > create them. > Yes, so the problem occurs when there's no decoder needed in decodebin2 and demuxer wants to do buffer_alloc.
oh right, because the pad_alloc is not decoupled with the multiqueue.
Created attachment 109883 [details] [review] use buffer_alloc instead of pad_alloc if pad is blocked
Created attachment 109886 [details] [review] use object lock and macros for both checks
Any news on this? The last patch seems to improve the situation at least
*** Bug 588262 has been marked as a duplicate of this bug. ***
The patch didn't fix it for 588262 because the multiqueue's srcpad might be blocked AND linked and it will forward the alloc to the next pad/element, that can be blocked.
I think we have changed all demuxers now to not ever do a pad_alloc_buffer.
Can this be closed as OBSOLETE ? In 0.10 we've fixed it by making demuxers not pad_alloc IIRC, and in 0.11 this isn't really a problem any longer, is it? (And pad probes/blocks can be done with much more fine-grained control).
Yes, for 0.10 it's fixed in all demuxers and for 0.11 it's completely different