[Overflow] Re: [gst-devel] Possible collaboration with Overflow

[Jean-Marc V. <va...@ge...>]

> I'm compiling Overflow right now, and like what I see.  It sounds like the
> perfect tool to work on one of my other pet projects, which is codec
> development (new code, not new implementations), among other things.

Don't know whether you mean audio coding or video coding (or both), but Overflow
already has lots of stuff for audio coding (I did my master in a speech coding
group). There's some image processing stuff, but it's a bit outdated. 

Also, tell me if you have any problem compiling... I'm having a hard time
dealing with all the different C++ compilers. 

> At GUADEC I was approached by a guy working on another somewhat related
> project (graph of decision processing, that he compiles to C, used for
> things like deciding whether to grant a loan or not) that has a *MEGA*
> canvas-based graph editting system called Seashore.  He says it'll be out
> (LGPL'd) in a month or so, if there is enough interest in collab between
> various graph-based projects like GStreamer, Overflow, aRts, etc., I can
> probably convince him to release a copy to us earlier, for feedback and
> such.

I'd like to see that... I think the GUI is the weakest point in Overflow.

> Seashore is based on the AA canvas, and as such has all sorts of neat
> interaction stuff such as alpha-fading links and such.  More importantly,
> it has massive graph-structuring code, with spline links and all that.
> From just 5 seconds looking at it, I was already drooling.
> 
> I think that Seashore would provide the perfect basis for all these
> projects, and would implicitly allow editting of one graph inside the
> other, which would be a *killer* feature.  The one flaw (and the reason I
> want to get ahold of code now rather than later) is that he didn't design
> it with arbitrary embedding in mind, as the GStreamer editor was.  In
> gsteditor, as in GStreamer itself, a container *is* an object.  You can
> place a container in the graph and it acts like any other object, except
> it's got another graph inside of it.  This is the GUI widget model, and
> it's very very powerful.

In Overflow too, the "Network" class (container) derives from the "Node" class
(toplevel processing object class). However, I'm not sure that we really want to
have the GUI object for a Network "embedded" in another network. The reason for
that is that it has to be possible to include two instances of the same network.
Just like in C (or any other language) you can make two (or more) calls to the
same function. In Overflow, I have a tab for each network I define and I'm free
to use it as a Node any number of times I want. (Does this paragraph make any
sense?)

> Another thing that happened at GUADEC was serious discussion between
> myself and Stefan Westerfeld, the aRts author.  We agreed to build plugins
> for each others systems that embed each other.  I've hit a roadblock with
> the aRts plugin for GStreamer, but it's just because I don't understand
> aRts enough.
> 
> The same thing could be done for Overflow, and even the third leg of
> Overflow<>aRts plugins.  Then with graph-builder integration we could do
> some seriously cool stuff.

That'd be cool... I think Overflow fits well for handling the lower level
operations, because it's quite fast at handling small elements (like audio
frames, ...), because it's limited to pull-only. For the higher-level stuff,
gstreamer might be better though (sorry, didn't have time to try GStreamer yet).

> > * Common base multimedia libraries: We could probably share the low-level
> > audio/image/... processing routines.
> This is very much related to my codec interests.  On codecs.org I have
> several packages, including libcodec, which is specifically designed to do
> just this.  Someone on IRC pointed out that libcodec is potetially too
> narrow a name, since the same specialization architecture (each function
> can have arbitrary, run-time switchable implementations optimized for
> different architectures) can be used in all sorts of projects.

That could make interesting Overflow Nodes... 

So, what do you think the next step should be?

	Jean-Marc

-- 
Jean-Marc Valin
Universite de Sherbrooke - Genie Electrique
va...@ge...