wearable/docs/slides/outline

   1 Introduction (1)
   2         (sorry, no cool logo/graphic yet, ideas?)
   3         GStreamer is a library and set of tools to build arbitrary,
   4          reconfigurable filter graphs.  It derives from the OGI Pipeline
   5          and DirectShow (docs, no experience), and is in its second
   6          generation (first was completed/abandoned *in* Atlanta on the
   7          way to the Linux Expo).
   8         0.1.0 release is scheduled for Oct 31, 1999.
   9         Will cover Background, Goals, Design, and Futures
  10 Why do we need this?
  11         launch reads the command line to create the graph, from .so's
  12         Connections (queues) are made by launcher, lots of switchout code
  13         Argument handling is messy, at start-time only
  14         ...thus there is basically only one state: running
  15         There is no real master process capable of seeing the whole
  16          pipeline as a graph, so wiring A->B->C with some backchannel
  17          (parameter, not data stream) from C to A is hard
  18         Channels try to do IPC, file, and network I/O, excess abstraction
  19 Goals (1)
  20         Provide a clean way to both build graphs and write new elements
  21         Make things easier by providing auto-connect, stock sub-graphs
  22         Include tools sorely lacking in OGI pipeline, like editor, saves
  23         Enable Linux to catch up with M$'s world, allowing commercial
  24          plugins to a stable API (as of 1.0) so we don't end up with N
  25          wheels from N-M different people (multiple projects)
  26 Overview (1)
  27         Object hierarchy capable of run-time discovery, based on GtkObject
  28         Deeply nested parent-child relationships enable threads, blackboxes
  29         Buffers can point to anything, are typed, and can carry metadata
  30         Plugins can be loaded at any point, and registry reduces loads
  31         Symbiotic editor lets you design/run/save graphs visually
  32 What are filter graphs? (1)
  33         Filters take data in and spit data out, doing something to it
  34         Filters have N>=0 inputs and M>=0 outputs
  35         Filter graphs are many filters connected together, like a circuit
  36         The goal is typically to move data from 'left' to 'right', towards
  37          some kind of user-visible conclusion, i.e. audio or video
  38 Architecture (3?)
  39   - Graphs of Elements
  40         (here lies screen-grab from editor)
  41         Element is core Object, Bins hold (and are) Elements
  42         Pads are fundamental to an Element, are cross-wired with pointers
  43         Since Bins hold Elements, and Bins are Elements, Bins hold Bins
  44         'Ghostpads' provide interfaces for Bins without native interfaces
  45 #       Threads are type of Bin that actually run in separate threads
  46
  47   - States
  48         (table of states, invariants, and descriptions)
  49             COMPLETE    Element has all needed information
  50             RUNNING     Element has acquired resources, ready to go
  51             DISCOVERY   ... (unimplemented)
  52             PREROLL     ... (unimplemented)
  53             PLAYING     Element is actively trading data
  54             PAUSED      Special state where things just don't run (?..)
  55         States are used to keep elements in check
  56
  57   - Buffers
  58         Buffers designed to be versatile, with arbitrary typing/metadata
  59         Has pointer to data, length, so can point to someone else's data
  60         Type system (crude so far) ensures buffers don't go stray
  61         Metadata can be attached, such as the audio parameters
  62         Ref-counting and copy-on-write avoids most copies, not complete
  63         Sub-buffers can be created from bigger buffer, limitting copies
  64 Gtk+ Object System (2)
  65   - Pros
  66         C-language object system, well tested (Gtk+, Gnome...)
  67         Arguments of any fundamental type, read/write, built-in hooks
  68         Signals used for hooks into object events, overridable
  69         Run-time discovery of args, signals (quarks)
  70   - Cons
  71         No multiple-inheritance, though I haven't *needed* it
  72         There are some holes (can't attach quarks to *eveything*)
  73
  74   - Design
  75         Classes, instances are structs; 1st item is parent class
  76         Type system allows clean casting, ^^^^^^
  77         Arguments are set/get by string, use functions to do the work,
  78          thus setting an arg might trigger a redraw of the GUI
  79         Signals are strings, use marshallers, various firing methods
  80 Basic GStreamer objects (1)
  81   - Elements
  82         (show class,instance structs)
  83         Very simple, just provides a means to handle pads, state
  84   - Bins
  85         (show class,instance structs)
  86         Supports children, handles group state transitions
  87 Pads (1)
  88         Pad list type, direction, and chaining function ptr
  89         When creating a sink pad (!src) you set the chaining function
  90         gst_pad_connect() sets the peers, and copies chain function to src
  91         Passing buffer to a src pad transparently calls the chain function
  92         (graph goes here...)
  93 Sources (1)
  94         Source provides functions to push data
  95         Regular push() function just takes next N bytes and sends them
  96         Async push_region() grabs N bytes at offset O and sends them
  97         EOF signal [will] reset the state from PLAYING down to !RUNNING
  98         "location" argument is global by convention, for filenames...URIs
  99 Connections (1)
 100         Special type of Filter that
 101 Threads (1)
 102         Special case of Bin that actually creates a thread transparently
 103         When RUNNING, thread exists, mutex/cond used to go [!]PLAYING
 104         Automatically determines how to start sub-graph
 105                 Looks for both Sources and Elements wired to Connection
 106         Will cooperate with Pipelines when threading is not available
 107 Typing and Metadata (1)
 108   - Types
 109         Based on MIME types, set up as quarks, and dealt with as int
 110         Usable entirely at run-time, since they're registerable by plugins
 111   - Metadata
 112         Also registered as an int, but must be compile time due to structs
 113         Have refcounts and CoW semantics, since they travel with buffers
 114 Plugins (1)
 115         Plugin architecture designed around class system
 116         Arguments and signals provide interface over standard base class
 117         Each Element defined by ElementFactory, which is queried by name
 118         At plugin load, any number of ElementFactories and Types registered
 119         Element registers against Type as source or sink
 120 Editor (2+?)
 121         (show filter graph snapshot, a different one, more complex)
 122         Built as a parallel object hierarchy on top of GNOME Canvas
 123         Every object in filter graph has equivalent in editor, plus some
 124         Canvas is designed with groups and signal-propagation, so...
 125         Why not build the whole thing as subclasses of CanvasGroup?
 126
 127         ...because updates get messy/recursive (the way I *was* doing it)
 128         Solution is to modify objects so they own Group rather than being
 129         Relatively trivial modification, but requires lots of repointering
 130         Still a genealogical mess of parents and children...
 131 XML
 132         The goal is to use XML heavily, with an eye towards DOM
 133         Used for both saving and providing pre-build components
 134         Both graph and editor will have namespace, they'll interleave
 135         A generic save function will exist for Elements, with hooks
 136         Saving an EditorElement will also save Element
 137         Also used for a plugin registry, to avoid loading all plugins
 138
 139
 140
 141
 142 leaky bucket is trivial
 143 applications - generic conferencing tool (repluggable codecs), mixing
 144  environment (data flow graphs)