No subject
Sun Feb 20 09:24:37 PST 2011
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.
> * Interoperability: If I understand correctly, GStreamer can be used as a
> library, just like Overflow, meaning that we might be able to plug Overflow
> networks/pipelines in GStreamer and the opposite.
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.
> * 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.
Right now libcodec has only basic routines for MPEG video decoding (motion
compensation, idct, yuv->rgb), but it has extensive specialization, such
that I had SSE2 (Pentium IV) versions of the mcomp routines before the P4
even shipped... <g> They don't yet compile because of the lack of
libsse.h, but details....
This architecture can be used for all kinds of math kernels, and thus
could provide the basis for a lot of codecs and media-processing
components.
> I've also got a question: Overflow does it's computations by pulling
> results, ie asking the last blocks for its output and letting
> everything propagate towards the input (recursivly). Is GStreamer also
> pulling on data, or is it pushing? Anyway, tell me what you think
> about all that...
GStreamer is actually a hybrid model. Elements can be written in two
ways: chained and looped. A chained element is ideally run in push model,
where each element operates on its buffer, and actually directly calls the
next (to the right) element on the stack. This only works in some cases,
like 1:1 filters, so the other model is looped. Each element exists in
its own cothread, and simply sits in a while() loop pulling buffers, doing
stuff, and pushing buffers. On each pull or push, as necessary, a
cothread switch is done to the peer element. This lets execution wander
back and forth as data is passed.
The critical issue here is that there is no 'scheduler' in the classic
sense. Everything is self-scheduling, assuming a viable plan. My current
project is making this plan construction incremental, so you can modify
the pipeline while it's running. Future enhancements can bring in
optimizations, like:
a -> b -> c -> d
...normally cothreads will cause switches a->b, b->c, c->d, d->c, c->b,
b->a, and repeat. But in some cases (b and c are 1:1 filters), you can
skip two switches and go a, b, c, d, and right back to a.
An even better case is if b and c are chained elements, they can be run in
the stack instead of in their own cothreads (which is a simplication in
place right now to keep in 'sane').
Erik Walthinsen <omega at temple-baptist.com> - System Administrator
__
/ \ GStreamer - The only way to stream!
| | M E G A ***** http://gstreamer.net/ *****
_\ /_
More information about the gstreamer-devel
mailing list