[gst-devel] (LONG) Extensive and unorthodox gstreamer use in app

Andy Wingo wingo at pobox.com
Wed Jun 26 13:22:02 CEST 2002

On Wed, 26 Jun 2002, Lee Braiden wrote:

> Hi all,


> I'm thinking of using gstreamer for my project, AMPU.

It's an odd application, but hey, it sounds possible. There's another
fellow looking to base his scientific data acquisition and processing
software on gst, so i suppose anything's possible..

> * How much of this is compatible with gstreamer's fundamental design
> concepts?  Do I need to forget about gstreamer and look elsewhere?  I
> think not, since my own diagrams for a system to implement this looked
> quite similar to what's in gstreamer, but maybe I don't understand it
> well enough -- I've only skimmed gstreamer's docs so far.

The GStreamer core is completely media-agnostic. There are no hardcoded
data types at all. That said, GStreamer isn't all that great for
sporadic data flow, it's more designed for constant flows.

> * Will gstreamer function OK within a daemon, without running o a GNOME
> display?

Yes, the core is GUI-independent.

> * Does gstreamer have a simple way to say in a GNOME client to say,
> "Build me a component for editing/viewing mimetype X, and display it in
> container Y" ?

For viewing media, we have a sample player object that is
GUI-independent, and a viewer/controller for GNOME. For your purposes,
you would probably need to build your own, though.

> * Is it possible to add internal datatypes and filters to gstreamer
> without polluting the wider gstreamer system?  Or perhaps it doesn't
> matter, as long as I use typenames which don't conflict with other
> things?

Yes, and yes.

> * More generally, how do you all feel about this?  Does anyone find this
> use of gstreamer inappropriate, or perhaps even offensive?  Would you be
> interested in any patches I might have along these lines, or would you
> prefer that I just adapt what code from gstreamer I need, add my own
> modifications, and keep them away from gstreamer entirely?

It does seem somewhat inappropriate, as a design decision, to consider
your problem to be that of a streaming system. I don't think that I
would do it this way. But, you know your problem better than I do; if it
makes sense to you, you might try some simple pipelines to see if it's
what you need.

If your patches are generally useful, we would certainly be interested
in having them.

> Thanks for your patience :)

No problem ;)



More information about the gstreamer-devel mailing list