GNOME Bugzilla – Bug 667430
gnonlin cant process flac files. Gives error
Last modified: 2013-06-25 22:06:53 UTC
This pipeline gives error gst-launch gnlcomposition \( gnlfilesource location=test.file.flac media-start=392133000000 media-duration=335200000000 start=0 duration=335200000000 \) ! audioconvert ! fakesink The error is ERROR: from element /GstPipeline:pipeline0/GstBin:bin0/GnlFileSource:gnlfilesource0/GstURIDecodeBin:internal-uridecodebin/GstDecodeBin2:decodebin20/GstFlacParse:flacparse0: GStreamer encountered a general streamer error. Additional debug info: gstbaseparse.c(2695): gst_base_parse_loop (): /GstPipeline:pipeline0/GstBin:bin0/GnlFileSource:gnlfilesouce0/GstURIDecodeBin:internal-uridecodebin/GstDecodeBin2:decodebin20/GstFlacParse:flacparse0: streaming stopped, reason error ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ...
Here's what I worked out so far from reading and comparing logs: A seek request goes through flacdec/flacparse down to the source, which fails to seek (this also happens for a normal playbin2 pipeline using, eg, Totem, and seeking works here). The baseparse class then tries to seek after the source fails to. This causes a flush-start event to be sent. When using the command line above, a pad in an internal uridecodebin is blocking, and this causes the pipeline to error out. In Totem, no such blocking pad is hit, and baseparse correctly continues seeking. See attached portion of logs showing what happens before the error, described above. I'm now stumped, so I guess we'll need someone who knows gnonlin to check whether that pad is supposed to be blocked at that time.
Created attachment 204936 [details] Log portion showing last lines before blocked pad
I just tested with git master of GNL and it seem to work now. Note the API change here: gst-launch gnlcomposition \( gnlurisource uri=file:///home/nicolas/Musique/test.flac start=0 inpoint=392133000000 duration=335200000000 \) ! audioconvert ! fakesink