GNOME Bugzilla – Bug 347085
some problems with wavparse
Last modified: 2006-07-10 12:16:06 UTC
Please describe the problem: I've had some issues with the wavparse element. Debug infos: INFO (0x804f0a8 - 0:00:00.059017000) GST_ELEMENT_PADS(18263) gstelement.c(821):gst_element_get_static_pad: no such pad 'wavparse_src' in element "wav-decoder" INFO (0x804f0a8 - 0:00:00.059130000) GST_ELEMENT_PADS(18263) gstutils.c(978):gst_element_get_compatible_pad:<wav-decoder> Could not find a compatible pad to link to converter:sink Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
Created attachment 68709 [details] source of test
This is not a bug, the code won't work like this (it was OK in 0.8, but isn't any longer in 0.10). wavparse has dynamic source pads, it will create those only when it has determined the type of data the file contains, so you can't link wavparse and another element right away, you'll have to watch for the pad-added signal and then connect the rest of the pipeline from there (similar to what you have to do with oggdemux or decodebin, see HelloWorld example in Application Development Manual). Where is this code from? Do we need to fix/update this anywhere?
Sorry, I attached the code now.
Thanks, I've seen the code you attached. Basically, this line will fail (for the reason outlined in the comment above it): /* link together - note that we cannot link the parser and * decoder yet, becuse the parser uses dynamic pads. For that, * we set a pad-added signal handler. */ gst_element_link_many (source, decoder, conv, sink, NULL); decoder ! conv can't be linked, because decoder does not have a source pad yet at this point, it will only add its source pad when it gets data (ie. after you change state to PAUSED or PLAYING).
Ok. Thank You.
Feel free to pop into #gstreamer on irc.freenode.net if you can't get it to work or have any questions :)