docs/random/states.new

   1 OUTDATED
   2 --------
   3
   4 Since the plan generation only happens as a result of the state mechanism,
   5 I'll describe that first.
   6
   7 It's supposed to be recursive, such that setting the state on a Bin
   8 recursively sets all the children.  However, this needs to be rethought
   9 somewhat, in light of some recent ideas on the actual definition of some
  10 of the states.
  11
  12 The mechanism is thus: When you call gst_element_set_state(element,state),
  13 it calls the change_state() class method.  The basic Element-provided
  14 version just sets or unsets the state.  A more complex element like the
  15 audiosink will switch on the state and do certain things like open or
  16 close the sound card on transition to/from various states.  The success or
  17 failure of these actions can determine whether or not the state gets
  18 [un]set as requested.
  19
  20 GtkObject signals enter in here, as whenever a state is successfully
  21 changed, the STATE_CHANGE signal is fired, which gives higher-level code
  22 the ability to do something based on the change.
  23
  24 The Bin's change_state function walks through all its children and sets
  25 their state.  This is where things get interesting, and where things are
  26 going to need to be changed.
  27
  28 The issue is what the states are and mean.  Currently the states are as
  29 follows (from gstelement.h):
  30
  31 typedef enum {
  32   GST_STATE_COMPLETE    = (1 << 0),
  33   GST_STATE_RUNNING     = (1 << 1),
  34   GST_STATE_DISCOVERY   = (1 << 2),
  35   GST_STATE_PREROLL     = (1 << 3),
  36
  37   GST_STATE_PLAYING     = (1 << 4),
  38   GST_STATE_PAUSED      = (1 << 5),
  39
  40   GST_STATE_MAX         = (1 << 15),
  41 } GstElementState;
  42
  43 COMPLETE means all the necesary information is available to run, i.e. the
  44 filename for the disksrc, etc.  RUNNING means that it's actually doing
  45 something, but that's fuzzy.  PLAYING means there really is data flowing
  46 through the graph, where PAUSED temporary stops the flow.  PLAYING &&
  47 PAUSED is the same idea as !PLAYING, but there are probably going to be
  48 many cases where there really is a distinction.
  49
  50 DISCOVERY is intended for the autoconnect case, in those instances where
  51 the only way to determine the input or output type of some pad is for an
  52 element to actually process some data.  The idea in that case is that the
  53 source element would be responsible for sending the data non-destructively
  54 (in the case of a network client, it would have to save it all up, unless
  55 it has seek capabilities over the network), and all downstream elements
  56 process it in such a way as to not hose their own state.  Or rather, when
  57 they cease to do discovery, they completely wipe their state as if nothing
  58 ever happened.
  59
  60 PREROLL is a local state, used for things like sending the first half of
  61 an MPEG GOP through the decoder in order to start playback at a frame
  62 somewhere in the middle of said GOP.  Not sure how that will work,
  63 exactly.
  64
  65
  66 The issue is that these states aren't layered, and it most certainly isn't
  67 the case that a container isn't able to be of a certain state unless all
  68 of its children are.  I guess I should explain the idea of reconfigurable
  69 pipelines:
  70
  71 Build an MP3 player, give it the ability to use audio effects plugins.
  72 Since you don't want to have to start the stream over again (especially if
  73 it's a network stream) every time you change the effect.  This means you
  74 need to be able to freeze the pipeline in place to change it, without
  75 taking too much time.
  76
  77 This matters when you consider that certain state changes should render
  78 various state bits invalid.  In the FROZEN state these won't happen,
  79 because the assumption is that they're temporary.
  80
  81 If you haven't noticed by now, the state system isn't entirely
  82 self-consistent yet.  It needs work, and it needs discussion.