How to reduce gstreamer library size &startuptime

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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.

> 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() ?

[...]

> -----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




[Index of Archives]     [Linux Embedded]     [Linux ARM Kernel]     [Linux for ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux Media]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux