After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 701856 - qtdemux: Does allocation queries before setting caps on all pads
qtdemux: Does allocation queries before setting caps on all pads
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal blocker
: 1.1.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2013-06-08 16:08 UTC by Mathieu Duponchelle
Modified: 2013-06-19 09:08 UTC
See Also:
GNOME target: ---
GNOME version: ---

faulty file (497.06 KB, video/quicktime)
2013-06-08 16:08 UTC, Mathieu Duponchelle

Description Mathieu Duponchelle 2013-06-08 16:08:50 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.
Comment 1 Sebastian Dröge (slomo) 2013-06-08 16:40:16 UTC
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.

Comment 2 Sebastian Dröge (slomo) 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?
Comment 3 Sebastian Dröge (slomo) 2013-06-11 08:00:08 UTC
(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.
Comment 4 Sebastian Dröge (slomo) 2013-06-19 09:08:09 UTC
commit b001da292626c16c3cfa995585673380f65a9f4f
Author: Sebastian Dröge <>
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