GNOME Bugzilla – Bug 760770
compositor: a queue element is required when connect uridecodebin with compositor sink
Last modified: 2016-05-22 19:40:10 UTC
when use compositor to composite two or more videos from uridecodebin, a queue element is necessary to be added between uridecodebin and a compositor sink, like: gst-launch-1.0 compositor name=comp sink_1::xpos=320 sink_1::ypos=240 ! ximagesink display=:0 uridecodebin uri=file://$FILE ! queue ! comp.sink_0 uridecodebin uri=file://$FILE ! queue ! comp.sink_1 those queues element requirement is new for gstreamer 1.6.0, gstreamer1.4.5 doesn't require those queues. If remove the "queue" in above command line, then the command line will not work,and will get following error: ----------------------------------------------------------------------------- keke@keke-virtual:$ gst-launch-1.0 compositor name=comp sink_1::xpos=320 sink_1::ypos=240 ! ximagesink display=:0 uridecodebin uri=file://$FILE ! comp.sink_0 uridecodebin uri=file://$FILE ! comp.sink_1 Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Redistribute latency... Redistribute latency... Redistribute latency... (gst-launch-1.0:3445): GStreamer-CRITICAL **: Padname sink_1 is not unique in element comp, not adding (gst-launch-1.0:3445): GStreamer-CRITICAL **: Padname '':sink_1 does not belong to element comp when removing (gst-launch-1.0:3445): GStreamer-CRITICAL **: Padname sink_1 is not unique in element comp, not adding (gst-launch-1.0:3445): GStreamer-CRITICAL **: Padname '':sink_1 does not belong to element comp when removing Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock ERROR: from element /GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin1/GstDecodeBin:decodebin0/GstQTDemux:qtdemux1: GStreamer encountered a general stream error. Additional debug info: qtdemux.c(5306): gst_qtdemux_loop (): /GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin1/GstDecodeBin:decodebin0/GstQTDemux:qtdemux1: streaming stopped, reason not-negotiated Execution ended after 0:00:00.002658137 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... -------------------------------------------------------------------------
I can't reproduce this here with git master, but the problem here seems to be that sink_1 is requested multiple times from compositor by gst-launch. Not sure why it would do that. Can you run in a debugger and check what the pad name is that is passed to gst_element_request_new_pad() in all cases, and where it comes from?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!