[gst-devel] State issues for Bins

[Erik Walthinsen]

I'm working up a list of issues, here's the first set:

Bins:

Do we want to generate the plan before or after getting all the children
set?  I would think that a plan may be dependent on the prepared state of
the children, so I would vote for after. 

Does the order matter when setting the children?  Currently it follows the
order they were added, but I think the order should be derived from the
connection order.  Which end it should start from I'm not sure.  This begs
the next question. 

Do we want to have states travel up or down the pipeline at all?  We could
make this an option, in the form of a special buffer flag that causes the
system to try to set the state of an element before the buffer is pushed
or pulled.  This could be useful, but would have a constant drag on normal
operations even if never used.  (this could be mitigated by having single
test for a cluster of such bits, though how many such bits there might be
is questionable) 

Do we want to simplify the state-change process for elements by having
gst_element_set_state restrict state changes to one level at a time?  If
you tell something to go from NULL to PAUSED, it could simply loop setting
the state to READY, then PLAYING, then PAUSED, each time moving only one
level.  This would simplify most element's state handler. 

How do we deal with failed state changes?  Do we revert the entire Bin
back to the state we last attained (the above change would make that more
sane, too).  Or do we simply leave things the way they are and return
FAILED? 

How do we deal with ASYNC returns from state changes?  The only place we
use this so far is in the thread code, where a state change requires an
acknowledgement from the thread itself.  It's highly broken right now,
since the thread never sets the state.  My plan was to make use signals,
but the question of context comes up, and thus thread safety.  The general
idea is that the Bin's change_state()  will attach a callback to the
change_state signal of the any element that says ASYNC, and keep a count. 
As they come back changed, the count drops towards zero, then finally the
Bin's state is set.  This means locking the count. 


         Erik Walthinsen <omega at cse.ogi.edu> - Staff Programmer @ OGI
        Quasar project - http://www.cse.ogi.edu/DISC/projects/quasar/
   Video4Linux Two drivers and stuff - http://www.cse.ogi.edu/~omega/v4l2/
        __
       /  \             SEUL: Simple End-User Linux - http://www.seul.org/
      |    | M E G A           Helping Linux become THE choice
      _\  /_                          for the home or office user