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 747190 - videodecoder: Sends GAP events before CAPS
videodecoder: Sends GAP events before CAPS
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-04-01 15:26 UTC by Vivia Nikolaidou
Modified: 2015-04-09 03:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Simple testcase (3.29 KB, text/x-csrc)
2015-04-01 15:26 UTC, Vivia Nikolaidou
Details

Description Vivia Nikolaidou 2015-04-01 15:26:36 UTC
Created attachment 300763 [details]
Simple testcase

When using decodebin on .mov files (qtdemux), it can expose pads without caps.

Simple test case attached, .mov file is here:

https://www.dropbox.com/s/01psx3a1pwolj9p/bbb_sunflower_480p_30fps_normal.mov?dl=1
Comment 1 Sebastian Dröge (slomo) 2015-04-01 17:01:49 UTC
The problem here is the GAP event that is sent by qtdemux in the very beginning for the empty edit list it seems. But qtdemux also seems to set the caps on each pad before it adds it... so something after qtdemux seems to do things wrong. Tim seemed to remember that queue sometimes seems to delay caps until a buffer (and apparently not until GAP too), but that has to be checked.
Comment 2 Sebastian Dröge (slomo) 2015-04-09 03:17:39 UTC
And the exact problem is that GstVideoDecoder receives the GAP event, and then forwards it after draining (draining nothing, there is nothing yet). And as it did not decode anything yet, it also does not know any caps yet.

The same bug was fixed for GstAudioDecoder some time ago, but arguably not correct. Just inventing random caps is not going to solve anything, and applications waiting for caps are still going to be confused (as the caps are random, more useful caps with the resolution or number of channels are coming at a later time). Not sure what to do about this, GAP events before any data are not great :)

Jan, any ideas? You fixed/broke the same thing in audiodecoder ;)



commit c24a1254c9f1f73e23a1471ce9dd08f513618c8b
Author: Jan Schmidt <jan@centricular.com>
Date:   Thu Dec 26 23:21:45 2013 +1100

    audiodecoder: Choose a default initial caps before sending GAP
    
    If there are no caps from the audio decoder when handling a GAP
    event - as when one is received right at the start on a DVD without
    initial audio - then choose any default caps for downstream and
    then send the GAP, so the audio sink has a configured format in
    which to start the ringbuffer.
    
    Also, make the audio sink reject a GAP without caps with a clearer
    error message.
    
    Fixes bug https://bugzilla.gnome.org/show_bug.cgi?id=603921
Comment 3 Sebastian Dröge (slomo) 2015-04-09 03:47:46 UTC
Let's try this for now... and see what breaks. Better than no caps at least!

commit f268f2be92b2f983e0f45af257afd4fbbc0e5e40
Author: Sebastian Dröge <sebastian@centricular.com>
Date:   Wed Apr 8 20:45:58 2015 -0700

    videodecoder: Try to invent default caps instead of setting none at all when getting a GAP event before CAPS
    
    Otherwise we would forward the GAP event without ever providing any caps,
    which then would make decodebin expose a srcpad without any caps set. That's
    confusing for applications and can lead to all kinds of interesting bugs.
    
    Instead do the same as already is done in GstAudioDecoder, and try to invent
    caps based on the sinkpad caps and the caps allowed by downstream and the
    srcpad template caps.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=747190