[Bug 671380] [playbin2] Negotiation of a format between decoder and sink not possible because linked too late
bugzilla at gnome.org
Tue Mar 13 02:01:09 PDT 2012
GStreamer | gst-plugins-base | 0.10.36
Sebastian Dröge <slomo> changed:
What |Removed |Added
Summary|Decodebin2 gives Unknown |[playbin2] Negotiation of a
|type, posting message and |format between decoder and
|firing signal with MI-X |sink not possible because
|plugins (regression) |linked too late
Ever Confirmed|0 |1
--- Comment #7 from Sebastian Dröge <slomo at circular-chaos.org> 2012-03-13 09:01:04 UTC ---
Ok, so this is what happens here.
* decodebin2 emitted the autoplug-continue signal with non-fixed caps (i.e.
* playbin2 checked in its autoplug-continue handler if the currently selected
(if any... otherwise *any* sink) supports these non-fixed caps with
gst_pad_accept_caps(). gst_pad_accept_caps() in 0.10 just checks if the pad
caps and the passed caps can intersect, which is the case here.
autoplug-continue returns FALSE because the sink claims to handle the caps
* decodebin2 exposes the pad with the non-fixed caps, playbin2 links it to the
sink, negotiation with the sink works
* decodebin2 does not emit the autoplug-continue signal with non-fixed caps and
waits until the caps are fixed
* The decoder decides to go with the wrong caps during negotiation because it
doesn't know what the sink could do, caps are fixated
* decodebin2 autoplugging works as usual with the now fixed caps, no sink for
video/x-va is found, stuff breaks
The reason why this now breaks is that in 0.10.36 decodebin2 waits until it has
fixed caps before calling autoplug-continue. This should be reverted IMHO but
reverting this requires to change the autoplug-continue handlers too. The
autoplug-continue handlers must not call gst_pad_accept_caps() (i.e. check if
the caps can intersect) but instead must check if the passed caps are a subset
of the pad caps. Otherwise this doesn't reliably work with non-fixed caps and
this was the exact reason why this change was done (e.g.
"video/x-mixvideo-private; video/x-va" would be accepted by
gst_pad_accept_caps() on a pad that only accepts "video/x-va". But this is
wrong, nothing is preventing the decoder from outputting
"video/x-mixvideo-private" instead. The non-fixed caps must only be accepted by
gst_pad_accept_caps() if *all* possibilities are accepted by the pad in
question). Unfortunately this doesn't fix this bug here but is conceptionally
I don't really see how this bug here can be fixed without breaking the more
common use-case. At least not in 0.10, in 0.11/1.0 something clever with the
acceptcaps/allocation queries could be done.
(FWIW gst_pad_accept_caps() in 0.11/1.0 doesn't check for an intersection
anymore but for a subset)
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.
More information about the gstreamer-bugs