GNOME Bugzilla – Bug 311413
use gst-launch to start a pipeline with thread, but that never works
Last modified: 2009-08-15 18:40:50 UTC
Please describe the problem: run: gst-launch filesrc location=<a mpeg file> ! mpegdemux ! queue { ! mpeg2dec ! xvimagesink } Always gets error like this: Warning : erroneous pipeline: could not link queue0 to mpeg2dec Steps to reproduce: 1. as above words 2. 3. Actual results: as above words Expected results: we should link queue and mpeg2dec correctly Does this happen every time? Yes Other information: After ddd into _gst_parse_launch() function, the input str is fine and match command line parameters well. But in after yyparse(&g), g.chain contains element --- thread, but nowhere find elements that should be in thread element. in g.links, all src/sink pair are there. So after all elements in g.chain are put in bin but elements inside {} are not put in thread element, then try to link src/sink, we get error, I think the problem is here
honggang: can you try as ! { insead of { ! ? Not sure if it makes a difference, but it seems a bit more normal. Also, does it work without threads? Dropping severity, versioning as 0.8.x
wingo, we tried both, but the result is the same. it works fine without thread. Here we have a team trying to build up application based Gstreamer, we need time to pick up confidence about Gstreamer, do think it is reasonable to build commercial product based on it? Is it mature enough? Thanks -Honggang
The problem is not caused by thread,it is our wrong usage of connect Mpeg2demux and queue, since queue has any type pad, so it is unknown it will be connected with which pad of Mpeg2demux, to solve it, don't connect queue with Mpeg2demux. P.S. in info gstlaunch gives wrong information by connecting queue with mpeg2demux.
Yes, this is correct. In this example, queue ends up being linked to a pad that isn't shown in the pad template for mpegdemux, which is there because mpegdemux derives from mpegparse and isn't removing the pad (which it probably should do) In any case, the correct solution is to ensure that queue gets linked to the correct pad of mpegdemux by either: a) specifying a pad in the launch line, eg "gst-launch filesrc location=<a mpeg file> ! mpegdemux .video_00 ! queue { ! mpeg2dec ! xvimagesink }" b) In an application, perform the link yourself by connecting to the 'new-pad' signal of mpegdemux and linking it to the queue only when a video/mpeg pad is created.
Jan, thanks for your comments, but we tried your suggestion that connect mpegdemux.video_00 with queue, we got another error -- says " Link without source element", I think it is caused by no video output from video_00 pad or maybe the pad name is wrong?