[Bug 701856] qtdemux: Does allocation queries before setting caps on all pads

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=701856
  GStreamer | gst-plugins-good | git

--- Comment #2 from Sebastian Dröge <slomo at circular-chaos.org> 2013-06-11 07:41:21 UTC ---
So the only solution I see here to fix that in general is to switch demuxers to
having a separate streaming thread per stream, e.g. with the help of a demuxer
base class. And that way we could also move some of the multiqueue
functionality in there.


The specific problem here right now is that decodebin waits until all pads are
blocked before they are exposed, so it will block and expose after all pads
received the segment event after the caps event or ... block because of the
allocation query. Serialized events are decoupled from the sender via queues,
so no problem here. Serialized queries however are not decoupled, causing this
deadlock.


Possible workarounds right now would be:
1) Don't allow demuxer to do allocation queries from their single streaming
thread (similar situation as in 0.10 with pad-alloc)
2) Let decodebin expose pads ASAP, i.e. don't wait until all pads are blocked
but only until autoplugging has finished
3) Let qtdemux push the segment events before the allocation query


2) and 3) only work reliable for the single-demuxer case. If we have nested
container formats (e.g. DV in MXF) this still would potentially cause deadlocks
as the second demuxer would need to finish too, which would happen after data
was pushed and thus potentially an allocation query happened.

2) might be a good idea in general, independent of this bug. I don't remember
why we do that, does anybody see a good reason for the blocking?

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.