GNOME Bugzilla – Bug 679038
flacdec fails in a gnonlin pipeline that works with other formats
Last modified: 2013-08-24 22:07:40 UTC
Created attachment 217492 [details] Python script implementing a pipeline capable of reproducing this issue In Jokosher we have a gnonlin composition which may contain various different formats of audio, most formats play without any issues, however FLAC files fail to play. A similar bug involving Ogg Vorbis was recently fixed (https://bugzilla.gnome.org/show_bug.cgi?id=675812), however the problem with FLAC seems unaffected by this fix and pre-dates the point at which the Ogg Vorbis bug was introduced in 0.10.35. I've created a quick python script (attached) which implements a simplified version of this pipeline and which can be used to reproduce this issue. When the uri for the uridecodebin is set to a Wave, MP3, Ogg Speex or Ogg Vorbis file (using the current version in git or pre 0.10.35) it should play correctly, however when it is set to a FLAC file an internal data stream error will occur. Using the script with a FLAC file produces the warnings: 0:00:00.163663171 23409 0x2a3b140 WARN flacdec gstflacdec.c:1297:gst_flac_dec_sink_event:<flacdec0> couldn't convert time => samples 0:00:00.163920800 23409 0x2a3b140 WARN baseparse gstbaseparse.c:2890:gst_base_parse_loop:<flacparse0> error: streaming stopped, reason error GStreamer encountered a general stream error. gstbaseparse.c(2890): gst_base_parse_loop (): /GstPipeline:pipeline0/GstBin:bin0/GstBin:bin1/GnlComposition:gnlcomposition0/GnlSource:gnlsource1/GstURIDecodeBin:uridecodebin0/GstDecodeBin2:decodebin20/GstFlacParse:flacparse0: streaming stopped, reason error GStreamer encountered a general stream error. 0:00:00.173751900 23409 0x2a3b140 WARN flacdec gstflacdec.c:1297:gst_flac_dec_sink_event:<flacdec0> couldn't convert time => samples 0:00:00.174277090 23409 0x2aac040 WARN adder gstadder.c:1258:gst_adder_collected:<adder0> error: Unknown data received, not negotiated
The cause is the same one that was left unexplained in bug #675812. When the newsegment event (or another one) comes through (decoder), pad gets exposed (by decodebin2 etc) and gnonlin performs seek. This interrupts the sending of headers (be it vorbis ones or flac ones by demuxer or parser) and things go astray after that (for instance in parser state etc). By only sending events when data has really been decoded, this scenario is avoided and one might do something like that for flacdec as well. However, on the one hand, in 0.11 flacdec is ported to audiodecoder and as such it should already be ok that way. On the other hand, IMO, this is partially covering up yet-another-problem that stems from having these headers flying around (non-atomically) in-stream rather than being delivered in caps or whatever event (which forces decoders and parsers to have all sorts of counter and state tracking to determine header or data state etc, and is also inherently non-atomic).
Is there any bug left left to be fixed here?
If I read myself right and see the current situtation properly, it should be OK in 1.0+, since flacdec is audiodecoder based and that one delays sending events (which delays exposing pad I still presume) until actual data is available. As such, decoder state should be OK by then and no risk of missing headers. It also seems flacdec now expects headers in caps anyway, which also helps. [Though it appears the ogg situation is not consistent as e.g. vorbisdec expects them in-stream]
More importantly, flacparse handles duration queries and seeking now, and we know it's plugged and has read headers already by the time flacdec is autoplugged (since flacparse needs to read the headers to set the output caps, which are needed for autoplugging to continue). > As such, decoder state should be OK by then and no risk of missing headers. It > also seems flacdec now expects headers in caps anyway, which also helps. > [Though it appears the ogg situation is not consistent as e.g. vorbisdec > expects them in-stream] As far as I can tell, vorbisdec parses the headers from the input caps (grep for "streamheader"). Let's close it. Please re-open or file a new bug if there's still an issue with 1.x after all, thanks!
(In reply to comment #4) > > As such, decoder state should be OK by then and no risk of missing headers. It > > also seems flacdec now expects headers in caps anyway, which also helps. > > [Though it appears the ogg situation is not consistent as e.g. vorbisdec > > expects them in-stream] > > As far as I can tell, vorbisdec parses the headers from the input caps (grep > for "streamheader"). Oops, it does indeed. My bad for missing that part :(