[gst-devel] Request for ideas: decoupled elements

in7y118 at public.uni-hamburg.de in7y118 at public.uni-hamburg.de
Tue Sep 30 07:20:01 CEST 2003


Woah, there's some great ideas in there. Thanks for your input. I'll come to it 
below.

Quoting Andy Wingo <wingo at pobox.com>:

> I'm not really qualified to talk about threading. But I'll do a little
> bit anyway ;)
> 
I don't think aanyone of us is really qualified to do so. We're all just 
pretending to know something all the time anyway ;)

> A cleaner solution, topologically, would have
> DECOUPLED elements exist without parents (i.e., they would not be
> children of any bin).
>
This is were you turned all my thinking around and it was absolutely brilliant.
We create elements that don't have schedulers. This is freaking brilliant.
My idea was always that elements _without_ schedulers are a special case of 
elements. No. Elements _with_ schedulers are a special case of elements. Our 
whole object model needs turning around :)
(This will mean quite some subclassing in the plugins should we do that, I'll 
think about that later.)
Now a whole object model falls into place. If we make sure that certain stuff 
holds for specific elements and make the schedulers basically operate on pads 
instead of elements, we can use something like this:

GstElement            - base element, doesn't know about schedulers
+ GstSchedulerElement - basic scheduler-aware element
| + GstChainElement   - chainbased
| | + ...             - identity, osssink, ...
| + GstGetElement (?) - getbased (could be the same as ChainElement?)
| | + ...             - filesrc, gnomevfssrc, ...
| + GstLoopElement    - loopbased
| | + ...             - avimux, alsasink, ...
| + GstContainer      - element containing other elements
|   + GstSpider       - autoplugger
|   + GstBin          - bin to add / remove elements
|   + GstRootElement  - element owning a scheduler for lack of a better name
|     |                 (need not have a parent)
|     + GstPipeline   - you know this
|     + GstThread     - you know this one, too
+ GstQueue            - unaware of any scheduler
+ ...                 - pipefilter, whatever

Man I so totally like this, I have probably overseen a major flaw with this.
Does this sound reasonable to you others? (Apart from needing to rewrite loads 
of the core and having a reason to use subclassing?)

> Again, I'm ignorant, and I don't know what the proper solution is. But
> how do you see my description of the problem? And let me know what you
> think about parentage as the way to investigate the solution to this.
> Wim if you're around a word or two would also be appreciated ;)
> 
Brilliant. My brain wants to marry you right now. My heart still prefers my 
girlfriend though.
I'm going back into my cave now.

Benjamin




More information about the gstreamer-devel mailing list