[Bug 671380] [playbin2] Negotiation of a format between decoder and sink not possible because linked too late

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=671380
  GStreamer | gst-plugins-base | 0.10.36

Sebastian Dröge <slomo> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
            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
           Severity|blocker                     |major

--- 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.

In 0.10.35:
* decodebin2 emitted the autoplug-continue signal with non-fixed caps (i.e.
"video/x-mixvideo-private; video/x-va")
* 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

In 0.10.36:
* 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
more correct.

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.