GNOME Bugzilla – Bug 671380
[playbin2] Negotiation of a format between decoder and sink not possible because linked too late
Last modified: 2013-08-16 09:50:03 UTC
When i upgraded the gstreamer from version 32 to version 36 , i see the video from playbin2 is not showing the video . After some tricks i tried to use decodebin2 from version 35 and it work with gstreamer .36 . After analysing the logs from gst 10.36 i see decodebin2 is emitting Unknown type, posting message and firing signal and after this no video is seen, and same logs are not seen in 10.35.
Created attachment 209010 [details] Logs with gstreamer 36 and decodebin2 plugin from 35
Created attachment 209011 [details] logs for version 36( gst and gst-base)
Does this happen with every file? Or only specific container/codec combinations? Could you attach a sample file with if doesn't happen with every file?
Created attachment 209072 [details] media file
This happens for mp4 , *.avi
The decoder seems to be able to output both video/x-mixvideo-private and some kind of video/x-va. The main difference seems to be that in 0.10.35 the decoder did a get_allowed_caps() on the source pad after getting the first buffer: gst_pad_get_allowed_caps:<mixvideodecoderh2640:src> getting allowed caps gst_pad_get_allowed_caps:<mixvideodecoderh2640:src> allowed caps video/x-mixvideo-private and in 0.10.36: gst_pad_get_allowed_caps:<mixvideodecoderh2640:src> no peer which makes it default to output video/x-va, which is where things start failing then.
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)
Is there any correct working patch available for this issue ?
No, as it's not clear at all what the proper solution for this bug would be
This is fixed in 1.1 now, playbin allows decoders to query the sink caps via the autoplug-query signal of decodebin.