[gst-devel] Request for ideas: decoupled elements
Andy Wingo
wingo at pobox.com
Wed Oct 1 01:32:05 CEST 2003
On Tue, 30 Sep 2003, in7y118 at public.uni-hamburg.de wrote:
> 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 :)
Hm. My own thoughts couldn't make that leap but I see how that's a nice
solution... I'm cringing to think what it would mean for existing plugins, but
let's consider the object model that you propose.
> GstElement - base element, doesn't know about schedulers
> + GstSchedulerElement - basic scheduler-aware element
Maybe...
> | + GstChainElement - chainbased
> | + GstGetElement (?) - getbased (could be the same as ChainElement?)
> | + GstLoopElement - loopbased
I wouldn't have these as subclasses. I think this degree of subclassing makes
GStreamer less flexible, and doesn't really solve any problems. For instance, in
soundscrape I plan to support multiple algorithms based on which input pads are
connected. In that case an element might be a get element, or maybe a chain, or
maybe a loop -- it depends at runtime. The kind of scheduling depends on what
pads you have, which can change at runtime.
I think that's the general principle with this level of refactoring: let
sleeping dogs lie ;) Maybe scheduled elements are better off as a subclass, but
we'd need to look at the benefits this would give us. Sometimes this sort of
change is better done in a non-OO way (with flags and sched-private data like we
have). Again, I'm unqualified ;)
Regards,
wingo.
More information about the gstreamer-devel
mailing list