See my comments. Thanks. Hi, Zhang Yanlong-PBVM47 wrote: > I do think for a simple gstreamer application, it can work well. But > if it is a little complex e.g. support diverse encoder/decoder/file > formats, static link may reduce the performance while initing. > > and we can also talk about plugins shared by several applications I don't think you can afford to statically link them into each application which needs them. I mean that select different encoder/decoder/file format during run-time according to different data stream e.g mpeg4 or h.264 > Another suggestion is that: > Because your app is used for specified embedded device, some code > optimization can be introduced. > For example, try to use gst_pad_alloc_buffer() insteand of > gst_buffer_new() to transfer data buffer between elements which can > prevent from alloc new buffer frequently. > > could you elaborate ? or did you mean gst_buffer_new_and_alloc() ? A call to gst_pad_alloc_buffer() is done when the element knows on which source pad it is going to push the data. This allows the peer element to provide special "hardware" buffers for the calling element to work on, thus reducing the number of memcpys required in the system. [...] > -----Original Message----- > From: gstreamer-embedded-bounces at lists.sourceforge.net > [mailto:gstreamer-embedded-bounces at lists.sourceforge.net] On Behalf Of > Nicholas Hannah > Sent: Friday, February 29, 2008 9:23 AM > To: gstreamer-embedded at lists.sourceforge.net > Subject: Re: How to reduce gstreamer library size > &startuptime > > Hi All, > > I have ported Gstreamer to a small embedded OS. > > I statically link all plugins that I need for a particular pipeline > and explicitly call their initialisation routines. This means I don't > need to scan for plugins or run any dynamic module loading code. I > haven't done any proper tests to see how this reduces running time or > code size but it is noticeably quicker to start up (especially when > debugging is turned on) than a standard install. Let me know if > anyone is interested in how I did this. > > it could be interesting to see what part of that could benefit other OS's I think. > As an aside I think that static linking is a good option for embedded > systems because: > > 1) small OS's don't always (usually?) have a dynamic loader or > dlopen(), > dlsym() etc, > embedded high level OS's do have at least a dynamic loader and thus can take advantage of shared object to reduce memory footprint when several applications using the same plugins run at the same time. > 2) as mentioned earlier, in embedded environments new plugins probably > won't be installed very often, so dynamic module loading is less > useful, > 3) switching off all dynamic loading code will result in overall > smaller code size and better performance. > > as already mentionned, this is not always true. > In my opinion it would be nice if Gstreamer had better support for > static linking. > > -- Benoit Fouet Purple Labs S.A. www.purplelabs.com
