GNOME Bugzilla – Bug 516031
flac within ogg container can't be played on Jokosher
Last modified: 2009-03-12 15:16:06 UTC
Please describe the problem: While I can playback flac within ogg via totem, playbin and decodebin, even with queue or audioconvert elements, I can't do after I import it in Jokosher, as it fails with errors about initializing supporting library and therefore oggdemux. Steps to reproduce: See https://bugs.launchpad.net/jokosher/+bug/190802 for details. I also tried two pipelines, which gave no error and played file just fine: gst-launch-0.10 filesrc location=file.ogg ! queue ! decodebin ! alsasink gst-launch-0.10 filesrc location=file.ogg ! queue ! decodebin ! audioconvert ! audioresample ! audioconvert ! alsasink Actual results: Jokosher fails to playback with two Gstreamer errors. Expected results: Jokosher playbacks imported file. Does this happen every time? Yes Other information: I recompiled gst CVS two times, and this bug still pops up.
Created attachment 105056 [details] Log of GST_DEBUG=2,flac*:5,ogg*:5
The original bug says: > 1. File created with gst-launch file location=test.flac ! decodebin ! flacenc ! oggmux ! filesink location=test.ogg That's where the problem is. The oggmux element happily accepts flac data, but it does not actually implement the defined OggFLAC mapping. The resulting files are just garbage. With a proper OggFLAC file (i.e. one not created with GStreamer), it should actually work just fine.
Then why pipelines and Totem can playback them? It ignores wrong mapping and flies FLAC content?
> The oggmux element happily accepts flac data, but it does not > actually implement the defined OggFLAC mapping. The resulting > files are just garbage. Wasn't this fixed ages ago (see bug #426044)?
Hmmm, seems so. Sorry for the noise.
Created attachment 130240 [details] [review] In the event handler, check if we have initialized the stream before using it. I can confirm this on latest git. The problem does not appear with playbin because there are no flush or EOS events sent to the flacdec until the data starts flowing. However gnonlin does flushing seeks before the audio starts playing because gnonlin often does not start at the beginning of the file. In the event handler, gst_flac_dec_sink_event(), two functions are called on the FLAC stream without checking if it has been initialized: FLAC__stream_decoder_flush() FLAC__stream_decoder_process_until_end_of_stream() Both these FLAC__*() functions modify the internal state of the FLAC stream. Later, when the buffers start flowing, gst_flac_dec_chain() tries to initialize the stream. the FLAC__stream_decoder_init_stream() call will fail because the previous calls to FLAC__*() changed the stream state so it is no longer in the initialized state. FLAC__stream_decoder_init_stream() fails with code FLAC__STREAM_DECODER_INIT_STATUS_ALREADY_INITIALIZED. My patch simply checks if we have initialized the stream in gst_flac_dec_sink_event(), and if we haven't, skip over any calls to FLAC__*().
looks good to me.
commit 73fac6e4ea5df98afc5a04cc267b0a89b1b10ad4 Author: Laszlo Pandy <laszlok2@gmail.com> Date: Thu Mar 12 16:10:25 2009 +0100 Don't call FLAC__ methods before it's initialized. Fixes #516031 In the event handler, gst_flac_dec_sink_event(), two functions are called on the FLAC stream without checking if it has been initialized: FLAC__stream_decoder_flush() FLAC__stream_decoder_process_until_end_of_stream() Both these FLAC__*() functions modify the internal state of the FLAC stream. Later, when the buffers start flowing, gst_flac_dec_chain() tries to initialize the stream. the FLAC__stream_decoder_init_stream() call will fail because the previous calls to FLAC__*() changed the stream state so it is no longer in the initialized state.