GNOME Bugzilla – Bug 701856
qtdemux: Does allocation queries before setting caps on all pads
Last modified: 2013-06-19 09:08:09 UTC
Created attachment 246310 [details] faulty file It's a MOV file with h264 / raw audio, similar to what a Canon 5D outputs. If you remove the audio, discovering works fine.
Yes, that's because qtdemux is broken and decodebin became a bit more picky about that :) Please be more descriptive in the bug reports in the future. Saying that it never pre-rolls for example would be more descriptive, and backtraces of all threads would help too usually for such things :) Problem is that qtdemux does allocation queries before setting caps on all pads. Thread 5 in the backtrace below. I think it does that in that place, and also another one. Needs to be fixed.
+ Trace 232028
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?
(In reply to comment #2) > 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? Actually this waits for a buffer (or serialized query) as sticky events are just passed through. I think the reason for this back then was that we only get caps on a pad if a buffer arrives. However 2) is not going to fix this bug here. The problem for this specific file is that the video stream requires a decoder (so buffers from the demuxer before the final caps are known), but the audio stream is raw audio and thus does not require buffers. So even if we do 2), this won't be fixed... as qtdemux would block on the allocation query instead of sending buffers to the video decoder to allow it finding out the final caps. So 2) is not a solution, and in general only minimally useful. Unfortunately that makes 3) not a solution either. So only 1) is left.
commit b001da292626c16c3cfa995585673380f65a9f4f Author: Sebastian Dröge <slomo@circular-chaos.org> Date: Wed Jun 19 11:06:37 2013 +0200 qtdemux: Disable usage of allocation queries This can only reliably work if demuxers have a separate streaming thread per srcpad. This should be done in a demuxer base class, which integrates parts of multiqueue https://bugzilla.gnome.org/show_bug.cgi?id=701856