Re: GStreamer for Media Library


I am coauthor of GDAM, a sound editing program.

When writing gdam, we cycled through many frameworks,
one using threads (pthreads) and two client/server architectures.

The way it is now, that we are quite pleased with, is a
client/server all in C, written with just the facilities
gtk/glib provide.  (er except libglade and libxml now...)

We looked at/tried briefly gstreamer, but I was unable to
make a satifactory mixer in it.  [basically the sources
weren't able to block for input, which i needed].  Perhaps
gmf suffices, perhaps not, I found it rather confusing,
at the time it was pretty minimal and I certainly didn't
want to be the guinea pig there...

In any event, I wrote my own, and that was fun.
And I believe no library of this depth could completely
satisfy everyone ... what are really needed, are a clear
CORBA interface that everyone can comply to / use.

The rest is a bunch of details no one will agree on.

I think I'll get back out of this now :)

Thanks for listening,

On Thu, 23 Mar 2000, Erik Walthinsen wrote:

> On Fri, 24 Mar 2000, Nicholas Francis wrote:
> > I very much like GStreamer. My only concern is that it appears to have been
> > designed to be a system that is cool, which is not neccessarily the same as
> > that it is cool to use it...
> No, it was designed to solve the problems I saw with an existing project,
> the OGI pipeline.  It happens to be a cool design (IMO), and from the
> application-writer's perspective I believe it's quite a sane API.  Also
> consider that it's a low-level API, having to do with the filter graphs
> themselves, not the higher-level concepts I would expect GML to have.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]