From: Tim-Philipp M. <t....@ze...> - 2010-03-04 12:08:10
|
On Thu, 2010-03-04 at 11:47 +0000, Georg Sauthoff wrote: Hi, > filesrc location=some.mp3 ! mad ! audioconvert ! audioresample ! alsasink > it is no problem to to command pipeline state changes > (...) > But with a pipeline like > filesrc location=some.ogg ! oggdemux ! vorbisdec ! audioconvert ! audioresample ! alsasink > or > filesrc location=some.mp3 ! decodebin2 ! audioconvert ! audioresample ! alsasink > the state change sequences fail: > GST_STATE_PLAYING -> READY -> ***FAIL*** PLAYING > or > PLAYING -> READY -> ***FAIL*** PAUSED -> PLAYING > > Error was: gstoggdemux.c(3251): gst_ogg_demux_loop (): > /GstPipeline:pipeline0/GstOggDemux:oggdemux0: > stream stopped, reason not-linked message: Internal data stream error. > > Which looks to me like, hm, a bit kryptic. > > Obviously, I am missing something about the use of the gstreamer > API. What is the problem with the last two > pipelines/state-change-sequences? The problem is with the 'dynamic pads' of oggdemux and decodebin2. The first pipeline is very simple: all elements have pads at all times, even in NULL state, and you can link all those elements from the start. The other pipelines however have elements with dynamic pads where the pads don't exist yet in NULL state but will only be created once you start the data flow. gst-launch does a lot of magic for these things under the hood, so that you can just write decodebin2 ! audioconvert etc. and it will try to create that link when decodebin2 creates a suitable pad. The problem is that gst-launch/gst_parse_launch() simply don't set up things in a way that would allow you to re-start the pipeline with that magic. Fixable, probably, but no one could be bothered to do that yet. You should probably just create a new pipeline in youre case, or use something like playbin2 which does all that internally for you. Cheers -Tim |