GNOME Bugzilla – Bug 698097
[regression] FLAC audio in an aspx stream does not play
Last modified: 2013-04-16 14:51:10 UTC
Created attachment 241612 [details] sample file Simply grab the attached sample file and try to use it with the following: $ gst-launch-1.0 filesrc location=tone24bit.aspx ! flacdec ! pulsesink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... ERROR: from element /GstPipeline:pipeline0/GstFileSrc:filesrc0: Internal data flow error. Additional debug info: gstbasesrc.c(2814): gst_base_src_loop (): /GstPipeline:pipeline0/GstFileSrc:filesrc0: streaming task paused, reason error (-5) ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ... And yet, if you try the exact same command with the last gst 0.10, it works fine and you get an audible tone: $ gst-launch-0.10 filesrc location=tone24bit.aspx ! flacdec ! pulsesink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstPulseSinkClock
Created attachment 241613 [details] GST_DEBUG=6 Debug log or it didn't happen.
(also, while I'm at it... I'm left wondering if bug #680115, which has been observed with ogg vorbis and FLAC, could be related)
Please try: gst-launch-1.0 filesrc location=tone24bit.aspx ! decodebin ! pulsesink or gst-launch-1.0 filesrc location=tone24bit.aspx ! flacparse ! flacdec ! pulsesink In 1.0 we now require parsers in front of many/most decoders.
Ah indeed, that works (I was reporting that issue on behalf of someone else). Isn't forcing a parser in front of something that used to not require one (ex: flacdec) going to add latency however?
Not necessarily (it depends on what's upstream, the format, and the implementation). Certainly not an issue when reading from a file. Parsing was done before as well, it's just that that code lived in the decoder instead of being in a separate element. If it ever is an issue in practice it can be fixed.