GScrea..., um, GStreamer 0.0.9 released

[Erik Walthinsen <omega cse ogi edu>]

OK, lame Halloween joke. And it's almost not Halloween anymore. Oh well.

This is the first public release of GStreamer, designed mostly for coders
who want to root around in the code.  Since most of my plugins aren't in
top shape right now, there's not much cool stuff to demo (besides being
able to *draw* an MP3 player in 15 seconds and hit Play, if you have a
working MP3 decoder plugin that is).

As such, be prepared to have to muck with the build process a bit, it
isn't fully polished yet.  I'll have a list of errata for 0.0.9 on the
homepage (see below) as soon as I have a chance tomorrow (yes, I already
have some...), and may even do a 0.0.9.1 before I get into the work of
making 0.1.0 more generally useful.

Here's the full text of my 'prepared' annonce:


GStreamer homepage: http://www.cse.ogi.edu/~omega/gnome/gst/

GStreamer 0.0.9
===============

GStreamer is a streaming-media framework written from the ground up, based
on concepts from the OGI Pipeline [1] and DirectShow [2].  It attempts to
provide an architecture that makes it significantly easier to write media
applications, ranging from audio players through high-end sound-processing
systems.  It is built on top of Gtk+ and GNOME.

At the heart of GStreamer lies the concept of a 'filter graph', which is
simply a number of objects tied together into a circuit of sorts.  Each
object can be a source, filter, or sink for data, with as many I/O pads as
necessary (for instance, an MPEG system-level stream decoder would have
one input and two outputs: audio and video).  Arbitrary filter graphs can
be constructed using type checking to verify the graph.  Containers can
contain filter graphs themselves, allowing for nesting and transparent
threading.

Plugins are used almost exclusively to provide filters.  The core
GStreamer package comes with numerous filters ranging from a simple file
source to mp3 decoders to visualization plugins.  All filter types are
registered by name, along with the types of data they can deal with, which
will make it possible in the future to automatically create filter graphs.


Why GStreamer?
==============

GStreamer was written in response to the various problems I saw arising in
the software used at OGI, where I'm a staff research programmer.  The OGI
Pipeline uses this architecture, but has more abstraction than I think is
necessary (making everything from interthread buffer passing and network
operations 'the same'), and is not set up for use outside of OGI (it's not
a library).

There's also a growing class of 'me too' software, headed up primarily by
the huge swarm of MP3 Players for GNOME, KDE, and every other environment
you've heard of.  Each of these has their own way of doing the actual
decode of the MP3, ranging from using mpg123 via pipes to incorporating
the code into their programs.  This massive duplication of effort is a
waste, and the obvious solution is what Micro$oft did long ago:
DirectShow.  DirectShow provides a common API for media operations, so if
you write a MP3 player, you can use whatever MP3 decoder is on the system.
If there are several, choose.

Linux has no such system (until now), which means adding support for the
latest format (can anyone say 'Sorenson'?) is something most people don't
even think about, just because you'd have to add it to all kinds of
programs for it to be anywhere universal (OK, I'm ignoring the fact that
most people use a hacked XAnim to do video, sue me).  With GStreamer, all
applications can take equal advantage of a single decoder, even if it's
binary-only (as the case may be with Sorenson).  No code is duplicated,
etc, etc.


And GMF?
========

I first learned about GMF at the LinuxExpo '99 in Raleigh, NC.  This was
literaly a day after I had finished and promptly abandoned the first
version of this package.  Since then, GMF has languished for 4 or 5
months, with no development.

I tend to disagree with the premise of GMF, which is that DirectShow is
good and should be copied basically verbatim.  I think using CORBA for the
filter graph is overkill for this kind of application, and will make
people less likely to write plugins due to the use of an ORB.  I'm not
convinced there are any serious advantages to using CORBA, and know there
are disadvantages (speed, ease of programming).

No, CORBA is not bad, CORBA is good.  I will be supporting CORBA at some
point in the future, but not as the primary interface.  CORBA will be
available as needed as a view onto the filter graph, no more.  All real
interaction with the filter graph should remain via the native interface.


What's here so far?
===================

The main library, located in gst/, is pretty stable.  I haven't touched
much code in there for a long time (read: a month), so it's reasonably
bug-free in its current state.  gst/elements/ contains standard elements
such as disk source, OSS audio sink, etc.  These are also reasonably
stable, such that their user-visible interfaces won't change drastically
in the near future.

The editor is pretty good, with some gaping holes in functionality.  It's
hard to crash (I haven't done so in weeks), and even lets you run the
pipelines you create (I've knocked dozens of pairs of socks off by drawing
an MP3 player in 15sec and actually having it play).

The plugins are all over the map.  They run the gamut of internal
interfaces, all the way back to some of the original mechanisms.  Anything
I've been using recently myself is working, the rest probably won't.

Specifically:
	au: parses .au files into raw audio, might work, might not
	effects:
		stereo: simplistic (broken) effect from xmms, should work
		volume: changes signal volume, should work
	mp3decode:
		mpg123: not complete, my primary hacking project as of now
		mpg123lib: doesn't work, won't be carried forward
		xa: works just fine if you have libxaudio.a...
		xing: worked a while ago, makes noise these days
	visualization:
		smoothwave: shows nifty eye-candy, works well
		spectrum: needs rewrite, untested recently
		synaesthesia: never worked properly, needs help
		vumeter: works fine, just provides volume data
	wav: does the same with .wav files, same state


Future plans
============

This is an 0.0.9 release, as should be obvious.  I was going to do 0.1.0,
but mpg123 was being enough of a pain that I don't think I can truthfully
call this 0.1.0.

As of 0.0.9, GStreamer is in interface deep-freeze.  Between now and 0.1.0
I will be focusing entirely on getting all the plugins back into
functional shape (or getting them working in the first place).  Once
that's done, it should be more play-safe.  From that point, I will proceed
to rewrite the way filters work to some degree, based on numerous
discussions at OGI.

>From that point I'll be focusing on buffer operations, specifically timing
and metadata (redesign the typing and metadata systems, design timing
system from scratch).  Then its on to video and related fun, as well as
some cool test applications.


More info
=========
You can find more info at the GStreamer home page:

http://www.cse.ogi.edu/~omega/gnome/gst/

There you'll find some cool screenshots of previous programs I've had
running (before the latest changes, etc., etc.) and even a full hour-long
talk on GStreamer I presented at work a couple weeks ago.  Much
information about the GStreamer architecture can be gleaned from there.

Also, in the GStreamer distribution itself you'll find a docs/ directory,
with docs/random/ containing lots of my rambling from various stages of
development.  Some are old enough to be obsolete, but there's a lot of
meat there (on the order of 28KB of raw text).

I'll also be setting up a mailing list sometime soon, so people can
discuss the project.  Stay tuned for more info on that.


Epilogue
========

Well, that's it for now, I'm going to sleep now.  Have fun hacking!


         Erik Walthinsen <omega@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