[gst-devel] state change stuff

[Thomas Vander Stichele]

Hi,

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

Wasn't there code already that had this order implicitly ? Or was that
too hard to fix ? What exactly was the problem in the first place ?

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

I guess that depends.  What code inside elements itself depend on this ?
Also, it's always been my understanding that state changes in a bin were
to be gradually, not one after an another.

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

Well - it's easier to fix bugs that are due to a clearly defined problem
than fixing bugs that are due to a combination of two orthogonal
changes.  Ie, separating the patches and fixing only one issue at a time
makes it quite a bit easier to evaluate the impact.  I can't tell right
now what exactly is causing all of my pipelines to break.

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

Me neither - but given the current way of synchronization in GStreamer,
doing it this way will only make sync worse.

To sum up, if the direction of changing states inside a bin has changed
from horizontal to vertical, I'd say that's probably a change that
should wait until 0.9

Thomas


Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
I'd give anything to see you baby
I'd give anything to see you smile
My baby doesn't want just anything
she wants everything
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/