State changes from PLAY -> READY -> PLAY only work with mad plugin?

[Georg Sauthoff]

Hi,

I am playing around with the gstreamer API and currently I am trying to
make a pipeline stop (works) and make it to play from the beginning
again (works just in one case).

In the test program I construct the pipeline via:

pipeline = gst_parse_launch(argv[1], &error);

With this example

filesrc location=some.mp3 ! mad ! audioconvert ! audioresample ! alsasink

it is no problem to to command pipeline state changes

via

gst_element_set_state(pipeline, state);

in such a way

GST_STATE_PLAYING -> READY -> PLAYING

or

PLAYING -> READY -> PAUSED -> PLAYING

With the above pipeline, these state changes work like expected.


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

For the ogg vorbis example:

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?

Best regards
Georg

PS: I am using gstreamer 0.10 under Ubuntu 9.10.


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Wim Taymans]

On Thu, 2010-03-04 at 11:47 +0000, Georg Sauthoff wrote:

> Hi,
>
> I am playing around with the gstreamer API and currently I am trying to
> make a pipeline stop (works) and make it to play from the beginning
> again (works just in one case).
>
> In the test program I construct the pipeline via:
>
> pipeline = gst_parse_launch(argv[1], &error);
>
> With this example
>
> filesrc location=some.mp3 ! mad ! audioconvert ! audioresample ! alsasink
>
> it is no problem to to command pipeline state changes
>
> via
>
> gst_element_set_state(pipeline, state);
>
> in such a way
>
> GST_STATE_PLAYING -> READY -> PLAYING
>
> or
>
> PLAYING -> READY -> PAUSED -> PLAYING
>
> With the above pipeline, these state changes work like expected.
>
>
> 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
>
> For the ogg vorbis example:
>
> 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?

oggdemux has dynamic pads and gst-launch does not support dynamic pads
after being set to READY. You have to write an application to properly
handle these cases.

Wim

>
> Best regards
> Georg
>
> PS: I am using gstreamer 0.10 under Ubuntu 9.10.
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Tim-Philipp Müller-2]

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



------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Georg Sauthoff]

On 2010-03-04, Tim-Philipp Müller <[hidden email]> wrote:

Hi,

> 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.

thanks for this info!

> 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.

I see - it would be very orthogonal, if this is fixed at some point.

> You should probably just create a new pipeline in youre case, or use
> something like playbin2 which does all that internally for you.

Ok. Should I open a documentation improvement request in the bug tracker
against

http://www.gstreamer.net/data/doc/gstreamer/head/manual/html/section-elements-states.html

? I mean, the paragraph could mention, what state transitions are likely
to fail with elements involving 'dynamic pads' (including an example
pipeline).

Regards
Georg


------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Tim-Philipp Müller-2]

On Thu, 2010-03-04 at 19:56 +0000, Georg Sauthoff wrote:

> > You should probably just create a new pipeline in your case, or use
> > something like playbin2 which does all that internally for you.
>
> Ok. Should I open a documentation improvement request in the bug tracker
> against
>
> http://www.gstreamer.net/data/doc/gstreamer/head/manual/html/section-elements-states.html
>
> ? I mean, the paragraph could mention, what state transitions are likely
> to fail with elements involving 'dynamic pads' (including an example
> pipeline).

You could file a documentation improvement request against the API docs
of gst_parse_launch() so we can add a warning there.

It's not that that state transitions are likely to fail in general for
these kinds of elements - it's just that gst_parse_launch()'s
behind-the-scenes magic only works once.

Cheers
  -Tim



------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel