[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gstreamer-devel
Subject:    Re: [gst-devel] recent wave of element additions
From:       Ronald Bultje <rbultje () ronald ! bitfreak ! net>
Date:       2004-06-25 19:29:53
Message-ID: Pine.LNX.4.33.0406252125490.21283-100000 () raq ! textinfo ! nl
[Download RAW message or body]

Hi,

On Fri, 25 Jun 2004, Benjamin Otte wrote:
> - a multifdsink should be implemented as tee ! fdsink  tee0. ! fdsink  ...
> anyway, instead of being a core element

Maybe, but maybe application authors think this is more practical. As a
solution, we need to start moving application-specific elements, such as
switch (libgstplay) and many, many others out of gst-plugins into the
respective application. Gst-rec already does this, so others should follow
this example. The advantage of this is that the element can be as broken
as it could be and barely perform the function that it needs to perform
and everyone will be happy because it *cannot be used outside its own
application scope*.

Gst-plugins, or more general all plugins in $libdir/gstreamer-$VERSION, is
to be used only for *generally appliccable* elements. Gst-core, on top of
that, is to be used only for *universally appliccable* elements.
Multifdsink doesn't belong in gst-core *or* gst-plugins, imo.
Videorate/audiorate might (not sure).

Ronald



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
gstreamer-devel mailing list
gstreamer-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
[prev in list] [next in list] [prev in thread] [next in thread]