[gst-devel] A trip down memory lane

Erik Walthinsen omega at temple-baptist.com
Tue Dec 19 07:42:51 CET 2000

At http://gstreamer.net/gnome-streamer.tbz2 you can find a copy of the
predecessor to GStreamer, coded back in the summer of '99 (sounds like a
pop song title...).

Wim and I went through some of the code tonight and found a large number
of similarities between that code and what we have now, as far as
fundamental design goes.  Quite a few of the examples looked a lot like
examples I'm using even today to work out complex scheduling stuff.

The code quickly became unmanagable as I worked myself into several
corners, so I eventually tossed it out completely.  Roughly the next month
was spent thinking about various holes in the design, and what I wanted to
see in a pipeline system.  About that time the idea of Bins popped into my
head, as a way to deal with threads and other stuff.  At some point I
started coding again, and within a few more months I had released
GScreamer, er, GStreamer 0.0.9, on Halloween '99.

Tonight I hope to finally get the scheduling system full worked out, with
a feature added that was intended from the very beginning of the Bin: the
ability to properly handle the bin-in-bin-in-bin-... case.  The new code
is capable of constructing a scheduling plan for any arbitrary hierarchy
of bin parentage.  The idea is to simply set the 'manager' for a given
element, and all the elements with the same manager are scheduled at the
same time.  This flattens out the relationships, since with ghost pads the
Bins actually don't exist as far as pad peering goes.

The trick is that you could have a bin-in-bin-in-bin structure, with a
real [p]thread down at the very bottom, and it will be given the chance to
schedule itself independently, the top-level parent will ignore the
thread's children.  This is because a thread is a 'manager' Bin.

A very interesting file in the above tarball is the doc/goals file.  It's
a long rambling document that starts from some of the (now mostly solved)
design problems with the OGI pipeline.  It starts with some simplistic
pseudo-code and evolves into what we have today, including threading,
connections, typing, autoplugging etc.  Even covers stuff we don't do yet,
like more complete buffer mutability properties and backwards-drawn

Actually, it's pretty scary how closely that document describes the
current system.

Anyway, I'll get back to coding the scheduling stuff.  It's very very cool
now, I'll try to explain it tonight as well.

         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

More information about the gstreamer-devel mailing list