GNOME Bugzilla – Bug 667337
[0.11] decodebin2: Failure to get chain initial caps
Last modified: 2012-10-18 20:20:42 UTC
Due to the new way caps are forwarded, the topology code in decodebin2 no longer manages to get the caps of the initial chain (i.e. the caps between typefind and the first demuxer/decoder/element). This not only raises a warning in some cases, but also results in discoverer getting a topology where the initial caps ... are ANY.
Created attachment 204667 [details] [review] decodebin2: Try harder to get initial topology caps Since caps are no longer 'shared' between two pads (but forwarded from source pad to sink pad) we end up with the first chain pad not having specified caps (i.e. typefind:src). This solves the issues by getting the pad's peer caps. It is not optimal since it will (for most demuxers) return the pad template caps, which might contain non-fixed caps (ex : with qtdemux "video/quicktime; video/mj2; audio/x-m4a; application/x-3gp")
Comment on attachment 204667 [details] [review] decodebin2: Try harder to get initial topology caps <slomo> bilboed: hmmmm... is there no gst_pad_peer_get_current_caps() that would get the current caps instead of the possibly non-fixed caps? <slomo> bilboed: also do improve the non-fixed caps you could intersect with the original pad's caps probably <bilboed> this case really is typefind ! somedemux <bilboed> current caps on the peer will also be ANY <slomo> bilboed: why is this only with the typefind ! demux case? <bilboed> actually <bilboed> wait a minute <bilboed> this doesn't make sense <bilboed> typefind:src *should* have caps <bilboed> (the caps it typefind'ed) <bilboed> let me re-investigate this
The problem is the following: * typefind does its job (typefinding) and the source pad gets scheduled in push-mode * decodebin2 connects it to the compatible demuxer (let's say qtdemux) * the demuxer gets activated and activates upstream as pull-based => typefind:src pad gets asked to be activated to pull-mode => changing the scheduling mode makes it first be de-activated (GST_PAD_MODE_NONE) => All events on the pad get dropped, including the caps * data flows normally, decodebin2 prerolls * When getting the topology ... typefind:src no longer has any caps I'm not 100% certain what's the best solution to this: * Don't drop caps events when deactivating pads ? * Have elements set again the caps if a rescheduling happened ?
Created attachment 204753 [details] [review] typefind: Send caps again after activation Avoids ending up in cases where typefind gets activated in pull-mode and caps never get sent.
Works fine here and probably is a good idea in any way :)
This was pushed ages ago... commit 7cef56076e828fa0d7f9568ddf5f5eb115f3a82a Author: Edward Hervey <edward.hervey@collabora.co.uk> Date: Fri Jan 6 16:39:04 2012 +0100 typefind: Send caps again after activation Avoids ending up in cases where typefind gets activated in pull-mode and caps never get sent. https://bugzilla.gnome.org/show_bug.cgi?id=667337