GNOME Bugzilla – Bug 675812
vorbisdec/oggdemux fail to work within a gnonlin pipeline that worked in 0.10.34
Last modified: 2012-06-12 10:46:43 UTC
Created attachment 213813 [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, as of 0.10.36 (and possibly 0.10.35) Ogg Vorbis files no longer play in this pipeline. Wave, MP3 and Speex files all continue to play without any issues. With 0.10.34 Ogg Vorbis worked correctly. Playing Ogg Vorbis files directly through a playbin still works correctly. 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 or Ogg Speex file it should play correctly, however when it is set to an Ogg Vorbis file an internal data stream error will occur. When playing an Ogg Vorbis file the following warnings are produced: 0:00:00.102591987 5171 0x22bfe80 WARN vorbisdec gstvorbisdec.c:465:vorbis_handle_header_packet:<vorbisdec0> error: couldn't read header packet (-133) 0:00:00.102829020 5171 0x22bfe80 WARN vorbisdec gstvorbisdec.c:628:vorbis_handle_data_packet:<vorbisdec0> error: no header sent yet Could not decode stream. gstvorbisdec.c(465): vorbis_handle_header_packet (): /GstPipeline:pipeline0/GstBin:bin0/GstBin:bin1/GnlComposition:gnlcomposition0/GnlSource:gnlsource1/GstURIDecodeBin:uridecodebin0/GstDecodeBin2:decodebin20/GstVorbisDec:vorbisdec0: couldn't read header packet (-133) Could not decode stream. 0:00:00.102909338 5171 0x22bfca0 WARN oggdemux gstoggdemux.c:1113:gst_ogg_pad_stream_out:<oggdemux0> could not submit packet for stream 03cf269c, error: -4 0:00:00.102934806 5171 0x22bfca0 WARN oggdemux gstoggdemux.c:4467:gst_ogg_demux_loop:<oggdemux0> error: Internal data stream error. 0:00:00.102945135 5171 0x22bfca0 WARN oggdemux gstoggdemux.c:4467:gst_ogg_demux_loop:<oggdemux0> error: stream stopped, reason not-negotiated
A similar problem is encountered with FLAC files, which was present in 0.10.34 (and earlier) releases as well. 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
A very weird behavior. Turns out that vorbisdec receives the first packet of the Vorbis stream (a header), starts initializing the libvorbis decoder, but does not receive the remaining two headers, though they are sent by oggdemux. Next packet received by vorbisdec is the first data packet. As it's not initialized yet, vorbisdec falls back to the headers in caps, but since it's already started to initialize, it fails as it tries to use a second copy of the first header as a comments header. So either something is withholding the two remainding headers, or should not send the first one in the first place. I'm a bit stuck at the moment, so I'm putting my findings here for now before I continue hunting.
Created attachment 215935 [details] [review] audiodecoder: push queued events only when we have a first buffer
This patch fixes the issue. I'm not certain about possible side effects, so I'll leave this here for comments instead of pushing. I think it should be OK since events are pushed before the first buffer, but better safe than sorry.
Seems correct wrt pushing events before the first buffer, pushed. commit f8b87110814d575bda07c717437296cecd8dbed7 Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk> Date: Fri Jun 8 12:43:41 2012 +0100 audiodecoder: push queued events only when we have a first buffer https://bugzilla.gnome.org/show_bug.cgi?id=675812
That's great, thanks very much. It looks like the issue with FLAC in similar pipelines is a separate problem then, so I'll make a new bug report for that one.