docs/random/states.new

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