GNOME Bugzilla – Bug 563728
parse: Links always pad ASAP but should wait until caps are known
Last modified: 2016-05-14 08:31:23 UTC
The following pipeline fails to work: gst-launch-0.10 -v filesrc location=/home/cschalle/Videos/Transformers.mov ! decodebin2 name="decode" decode. ! ffmpegcolorspace ! schroenc ! queue ! matroskamux name=mux ! gnomevfssink location=file:///tmp/test8.mkv decode. ! audioconvert ! flacenc ! queue ! mux. It gives me this error: 0:00:00.118053692 32477 0x8852050 ERROR GST_PIPELINE ./grammar.y:524:gst_parse_perform_link: could not link flacenc0 to queue1 WARNING: erroneous pipeline: could not link flacenc0 to queue1 I am certain its the matroska muxer which is the problem though as the pipeline works fine if I use the oggmuxer instead of the Matroskamuxer.
Not sure what is wrong here but the following pipeline works: gst-launch-0.10 audiotestsrc num-buffers=1000 ! flacenc ! matroskamux name=m ! filesink location=test.mkv videotestsrc num-buffers=100 ! schroenc ! m. Could you get a debug log with GST_DEBUG=matroskamux:5 ?
Created attachment 124194 [details] Full debug log
Attached full debug log as just matroskamux:5 didn't generate anything. I was also able to create a Audio only Matroska file, but here where I try to do both it mess up.
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of 544003 ***
For reference this works: gst-launch-0.10 filesrc location=/home/cschalle/Videos/sincity.mp4 ! decodebin name="decode" decode. ! ffmpegcolorspace ! schroenc ! queue ! matroskamux name=mux ! gnomevfssink location=file:///tmp/test8.mkv decode. ! audioconvert ! flacenc ! queue ! mux.audio_00 ~
This is actually not the same bug. The problem here is, that the queue after flacenc is linked to the muxer in the very beginning before flacenc is linked to it. This makes the queue srcpad have ANY caps and ANY caps are of course compatible with the video template of the muxer. To fix this gst_parse_launch should wait with the linking until caps are actually known. Also it should probably always link upstream to downstream
And for this we probably have to rewrite the parser almost completely... and then could probably rewrite it from scratch in plain C ;) This bug is fairly important IMHO as many applications use gst_parse_launch for creating muxing/encoding pipelines and they usually don't want to be bothered about pad template names anywhere.
*** Bug 618598 has been marked as a duplicate of this bug. ***
I don't have the power to change bugs, but this ought to be set to confirmed.
Created attachment 266758 [details] [review] link uplink prior to downlink may this be part of the solution. can someone please provide a minimal testcase?
It's not really part of the solution, sorry :) Thinking a bit more about this I don't think a generic solution is even possible. For the usual case we could only link pads after we got a buffer or caps on them (blocking probes)... but that would otoh break negotiation (upstream can't know what downstream wants via caps query). And even for the usual case with the request pads we can't do that without breaking negotiation this way. Maybe we should consider this bug as WONTFIX? gst_parse_launch() can't guess the intention of the pipeline, but a manually build pipeline can handle all cases depending on the intention just fine.
As per comment #11. gst-launch is a debugging tool..