GNOME Bugzilla – Bug 486758
queue element fails to re-negotiate caps upstream when sink windows resize
Last modified: 2007-11-09 15:13:58 UTC
to see the bug, just try the last pipeline listed bellow then resize the windows with your mouse. if you try like this "v4l2src ! queue ! ffmpegcolorspace ! ximagesink" or "v4l2src ! queue ! ffmpegcolorspace ! identity ! ximagesink" neither ffmpegcolorspace or identity accept the new size and the ximagesink just put a black area and everything works fine But, trying this: gst-launch v4l2src ! ffmpegcolorspace ! queue ! ximagesink when you resize it seems the queue re-negotiate the caps with ximagesink and then try to re-negotiate with ffmpegcolorspace which tries to re-negotiate with v4l2src that can't work in a size like 645x483 for example BR, Edgard
* plugins/elements/gstmultiqueue.c: (gst_single_queue_push_one), (gst_single_queue_new): * plugins/elements/gstqueue.c: (gst_queue_init), (gst_queue_push_one): Fix queue negotiation. If acceptcaps unconditionally returns TRUE, upstream is tricked into thinking it can suggest a format downstream while downstream does not support that format. The real problem is that core calls acceptcaps when pushing a buffer with new caps, for which we do a little workaround by setting the caps on the srcpad ourselves before pushing the buffer (until this is figured out). Fixes #486758.
*** Bug 466257 has been marked as a duplicate of this bug. ***