[gst-devel] state change stuff

[Benjamin Otte]

Quoting Thomas Vander Stichele <thomas at apestaart.org>:

> Hi,
> 
> some recent changes in the state change code have completely altered the
> behaviour of state changes in bins.
> 
> Before the changes, bins would go from NULL to PLAYING by making
> children pass through each state change together.  Ie, all kids would go
> from NULL to PAUSED first, and so on.
> 
> Currently, looking at the logs and changes, it looks to me that it
> directly brings each of the children into the final state before moving
> on to the next.  This seems a pretty big change, and alters order of
> state changes in all my current test pipelines.  That by itself is
> probably not that big of a deal, but it seems to me that the previous
> order of changing children's state was more correct and logical.
> 
> I'm assuming that, for example, this will increase the time between a
> source like v4lsrc being in PLAYING and its respective sink.
> 
> Is there something inherently better about the new order, or is it just
> by accident ?
> 
It's a side effect of making bins work correctly with state changes. Since it's
quite a bit easier to do (as in less code), I did it that way.
It's also easier to define the behaviour of how a bin changes states that way.
There's quite some code in the new autoplugger that can at any state change of
any element inside the bin change any other element's state in the bin. It might
also remove or add elements at will during state changes.
And then there's a bonus in that we find a lot of bugs inside elements that
depended on the implicit state changing order, which is clearly wrong.

But if people think bin's should change states the old way, it's also ok I guess.

I don't think relying on the speed of bin's state changes to get 2 elements
change states at nearly the same time is a good idea though. If you want that,
change the bin's state to paused, then change source and sink to playing, and
then set the rest of the elements to playing.

Benjamin