[gst-devel] gstreamer in an embedded environment

[Erik Walthinsen]

On Wed, 20 Jun 2001, Michael Nelson wrote:

> I'm considering gstreamer for an embedded device evironment (TV
> set-top-box). It seems like a great fit because software could then be
> written to be agnostic to the type of hardware in the box. All the apps
> have to do is use the autoplugging to construct a pipeline and the
> appropriate elements are assembled according to what is present. I have
> a couple concerns however.
I've been planning a device that's using just standard consumer hardware
for my own use, so this is very relevant to me.

> First is the lack of the concept of a hardware connection between
> elements. For example in a digital TV box the demodulator is hardwired
> to the demuxer. Since both are customizable I would like to have
> gstreamer elements representing each but have the connection between
> them default to a hardware connection with no buffers passing between
> them. (Both usually have the ability to write buffers to and from
> memory, but why do that when there is a hardware connection?)
>
> Any thoughts on the right way to implement this?
Hrm.  I guess I'd suggest a third subclas of GstPad, which is a fake pad.
Used only for the concept of connection, it would have some extra
functions for deal with passing channel-control data back and forth.  Of
course, would then need some way to overload the pads such that which pad
is actually attached (the fake pad with a hardware connect or the real pad
that has the hardware copy to RAM) depends on what the other pad is.  That
way the elements can transparently be reconfigured, i.e. if you have the
extra cycles and bus time, you could stick a filter in the middle of the
elements, then remove it, with no problems at all.  It would jump from
hardware connect to RAM and back, transparently.

> Second is the size of gstreamer. By my calculations gstreamer requires:
> libgst  219K
> libglib 166K
> libgtk  137K
> libxml  386K
>
> I know there is working going on to remove the dependence on libgtk and
> all the X dependencies and that will help a lot. To further reduce the
> code size I am thinking about removing all XML functionality (and
> therefore libxml) and stripping out portions of glib that aren't used by
> libgst. Any other ideas?

The GOBJECT1 branch is getting pretty clean now, we're just getting the
last few bugs worked out.  I expect it should merge into HEAD by the
weekend.  There are issues with the gtk and gnome-based apps when using
glib-2.0 (they're not ported), but we will either port them or come up
with some means for linking a complete mess of mismatched versions of
libraries (glib-1.2, gobject-2.0, gtk-1.2, gnome-1.4) and getting them to
work.  But in most cases people will either be building with gtk-1.2, and
using the apps, or building with glib-2.0 and building their own very
custom apps.

I've started to add #ifdefs around the XML code in my copy of HEAD, I'll
try to get that completed soon as well.  There are other large chunks of
code I've identified that can be removed.  This is part of stuff I'm doing
for work anyway, so it'll happen shortly.  Other issues include slimming
the resulting libs, including glib.  Static linking will handle a lot of
that, but plugins have to be dynamically linked right now anyway, and I'm
not sure how to go about mashing libtool into a static lib and dynamic
plugins without doing both (dunno if that's a problem, except for later
links).  I'm going to search for or write tools that will figure out which
symbols are and aren't used, and probably have to construct a linker
script to get only what's needed.

I've got a pretty tight goal for libgst.la, so getting it slimmed down
won't be a problem.  glib-2 will be a little harder, but with the
aforementioned tools we can do it.  gobject is gonna be the hardest to
slim significantly, because it's just got so much bloat.  There's gonna
have to be a significant push in the gobject code to refactor the whole
thing so it's smaller and faster.  At the same time various #ifdefs can be
put in to compile out some of the more excessively paranoid checks (the
bulk of the code afaict is paranoia).  Unfortunately, that's a longer-term
process, and probably post 2.0.0.  I've already started a little of that
though, I have a patch pending that removes 50-99.99% of the overhead of a
particular check, because they're redundant...

TTYL,
    Omega
    aka sedi_master for the day

      Erik Walthinsen <omega at temple-baptist.com> - System Administrator
        __
       /  \                GStreamer - The only way to stream!
      |    | M E G A        ***** http://gstreamer.net/ *****
      _\  /_