[gst-devel] State changes from PLAY -> READY -> PLAY only work with mad plugin?

[Tim-Philipp Müller]

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