GNOME Bugzilla – Bug 443081
[wavparse] fails to post error on FLOW_NOT_LINKED
Last modified: 2007-06-08 09:03:53 UTC
Please describe the problem: When I add the 'volume' plugin into my pipeline with a 11025Hz wav file, gst_element_set_state returns GST_STATE_CHANGE_ASYNC. If I wait for it to complete, it never does. Steps to reproduce: Well, on my machine you could run gst-launch filesrc location=/home/sfink/Content/sounds/applause.wav ! wavparse ! volume ! alsasink I'll attach the wav file. Actual results: Setting pipeline to PAUSED ... Pipeline is PREROLLING ... (never finishes) Expected results: Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... etc. Does this happen every time? Yes Other information:
Created attachment 89214 [details] Test sound file, 11025Hz
Probably not a bug, but wrong usage. There are raw audio formats that volume doesn't handle. There are also sample rates and raw audio formats that alsasink can't not handle (depends on your driver, device etc.). If gst-launch can't link two elements right away, it will wait to see if something in the pipeline creates a new pad later, hoping that might then work. This is probably what you're seeing here. Data never makes it to the sink, and gst-launch waits around for more pads. Try this: gst-launch-0.10 filesrc location=... ! wavparse ! audioconvert ! volume ! audioconvert ! audioresample ! alsasink or: gst-launch-0.10 playbin uri=file:///path/to/foo.wav
Ah, I understand. Thank you. That's definitely it, since other files (with other formats) work fine. My original test case *did* actually have the audioconvert and audioresample stages in, but only after the volume plugin. I'd mark this bug as invalid, but (1) I don't know if I have the rights, and (2) I don't understand this bugzilla's distinction between NOTABUG and INVALID. I had no idea that this would be the behavior, though, even after reading the developer's guide. I should really move this question to gstreamer-devel, but is there a way to say "everything is set up that is going to be set up, so if there are no more messages on the bus, then I expect everything to be in the PLAYING state and if something isn't, throw me an error message"? Or something like that? (I'd want it programmatically, so I don't care whether it can work automagically with gst-launch.) It just seems like an infinite timeout isn't the nicest way to detect format mismatches.
Actually, it should error out with a not-linked 'internal flow error'. Not sure why it doesn't do that for you, it does it for me. What GStreamer version are you using, ie. what's the output of $ gst-launch-0.10 --version ? I think this should have been fixed in the 0.10.12 release by this commit: 2006-02-04 Tim-Philipp Müller <tim at centricular dot net> * tools/gst-launch.c: (event_loop), (main): Catch errors during preroll (#320084)
% gst-launch-0.10 --version gst-launch-0.10 version 0.10.12 GStreamer 0.10.12 Unknown package origin I haven't modified the source.
Alright. Can't reproduce this here, so could you do the following then please: $ export GST_DEBUG_NO_COLOR=1 $ GST_DEBUG=*:5 gst-launch-0.10 playbin uri=file:///path/to/file.wav 2>dbg.log ... control-C after a few seconds once it stopped and hangs ... $ gzip dbg.log and attach dbg.log.gz to this bug report please?
Created attachment 89554 [details] Output of debug *:5 on hanging pipeline
It won't happen with playbin. The problem only occurs with an invalid pipeline, where a format conversion is required but the audioconvert element is not in the pipeline. I'll attach the output of gst-launch-0.10 --gst-debug-no-color --gst-debug='*:5' filesrc location=/home/sfink/Content/sounds/applause.wav ! wavparse ! volume ! fakesink Although first, I should note that if I run gst-launch-0.10 --gst-debug-no-color --gst-debug='*:2' filesrc location=/home/sfink/Content/sounds/applause.wav ! wavparse ! volume ! fakesink (or with alsasink at the end) I get the following warning: Setting pipeline to PAUSED ... Pipeline is PREROLLING ... 0:00:00.076083000 8447 0x8f58f40 WARN wavparse gstwavparse.c:1568:gst_wavparse_stream_data:<wavparse0> Error pushing on srcpad 0xb7200728, is linked? = 0 That's sounding like something simpler.
Right, my mistake, sorry. Thanks for the log. This is a bug in the wavparse plugin in gst-plugins-good 0.10.5. It is fixed in -good CVS though; this is the commit that fixed it: 2007-02-14 Wim Taymans <wim@fluendo.com> * gst/wavparse/gstwavparse.c: (gst_wavparse_class_init), (gst_wavparse_reset), (gst_wavparse_init), (gst_wavparse_destroy_sourcepad), (gst_wavparse_fmt), (gst_wavparse_parse_file_header), (gst_wavparse_stream_init), (gst_wavparse_perform_seek), (gst_wavparse_peek_chunk_info), (gst_wavparse_stream_headers), (gst_wavparse_parse_stream_init), (gst_wavparse_add_src_pad), (gst_wavparse_stream_data), (gst_wavparse_loop), (gst_wavparse_chain), (gst_wavparse_pad_convert), (gst_wavparse_pad_query), (gst_wavparse_srcpad_event), (gst_wavparse_change_state), (plugin_init): * gst/wavparse/gstwavparse.h: Update docs. Use boilerplate. Various code cleanups. When the bitrate is not known (bps == 0 or compressed formats) let downstream element guestimate the duration and position and don't generate timestamps or durations. Fixes #405213. Fix EOS and ERROR conditions in chain mode, we just need to forward the error flowreturn upstream. The problem was that wavparse would only post an error message if GST_FLOW_IS_FATAL(), which does not include GST_FLOW_NOT_LINKED, so it would just silently pause the streaming task and the application would never know that streaming stopped.