After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 443081 - [wavparse] fails to post error on FLOW_NOT_LINKED
[wavparse] fails to post error on FLOW_NOT_LINKED
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
0.10.12
Other All
: Normal normal
: 0.10.6
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-06-01 23:52 UTC by Steve Fink
Modified: 2007-06-08 09:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Test sound file, 11025Hz (44.20 KB, audio/x-wav)
2007-06-01 23:53 UTC, Steve Fink
Details
Output of debug *:5 on hanging pipeline (150.12 KB, application/x-gzip)
2007-06-07 16:47 UTC, Steve Fink
Details

Description Steve Fink 2007-06-01 23:52:25 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:
Comment 1 Steve Fink 2007-06-01 23:53:08 UTC
Created attachment 89214 [details]
Test sound file, 11025Hz
Comment 2 Tim-Philipp Müller 2007-06-02 09:37:14 UTC
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

Comment 3 Steve Fink 2007-06-04 17:19:02 UTC
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.
Comment 4 Tim-Philipp Müller 2007-06-05 08:43:32 UTC
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)
Comment 5 Steve Fink 2007-06-06 21:37:36 UTC
% 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.
Comment 6 Tim-Philipp Müller 2007-06-07 08:22:26 UTC
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?
Comment 7 Steve Fink 2007-06-07 16:47:42 UTC
Created attachment 89554 [details]
Output of debug *:5 on hanging pipeline
Comment 8 Steve Fink 2007-06-07 16:48:06 UTC
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.
Comment 9 Tim-Philipp Müller 2007-06-08 09:03:53 UTC
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.