[gst-devel] Bug in gst_bin_set_state ?

Andreas Rottmann a.rottmann at gmx.at
Thu Jan 20 10:17:42 CET 2005

"Ronald S. Bultje" <rbultje at ronald.bitfreak.net> writes:

> Hi,
> On Thu, 2005-01-20 at 14:55, Andreas Rottmann wrote:
>> I tried to get v4l2src to work with gstreamer, and in the process
>> found out that gst_v4l2src_change_state was never called when setting
>> the state of the pipeline.
> That indicates a state-change failure (probably due to failing caps
> negotiation)... Did you check the return value? Dunno about the patch.
> ;). The else { .. } will call _change_state,
Will it? It seems that the GST_CALL_PARENT_WITH_DEFAULT expands into
GST_ELEMENT_CLASS(parent_class)->set_state (element, state); which
resolves to gst_element_set_state_func(element, state), which doesn't
seem to iterate the children.

> which will call gst_bin_change_state(), which will call
> gst_bin_foreach(set_kid_state_func) on all kids per state instead of
> one-for-all, which is the correct behaviour if you ask me.
Yeah, that what you describe seems correct behaviour, but it seems to
me that this is not what happens in the original code when the state
changes (i.e. GST_STATE (bin) != state).

> I'm not totally convinced that the if { .. } is needed at all, but
> your patch doesn't seem right if you look at it that way.
I still don't understand how

    return GST_CALL_PARENT_WITH_DEFAULT (GST_ELEMENT_CLASS, set_state, (element,
            state), GST_STATE_FAILURE);

is going to ever invoke the children's change_state functions, since
GstElement doesn't even know about children. An that is what is called
when you call gst_element_set_state (pipeline, GST_STATE_PLAYING) on a
pipeline that is *not* in GST_STATE_PLAYING (without my patch).

Andreas Rottmann         | Rotty at ICQ      | 118634484 at ICQ | a.rottmann at gmx.at
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

It's *GNU*/Linux dammit!

More information about the gstreamer-devel mailing list