[gst-embedded] How to reduce gstreamer library size &startuptime

[Zhao Liang-E3423C]

If I do not misunderstand your meaning,  you want to combine all plugins
into application.
But if that, all plugins are combined together, the library will be very
big.
If  an application is a music player, it will combine all demuxers and
decoders together, and launch these at the same time whatever they are
needed for one special playback.
I think it will be slower than just loading application needed.

Best Regards
Zhao Liang
 

-----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: [gst-embedded] 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.

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

In my opinion it would be nice if Gstreamer had better support for
static linking.

Regards,

Nick


> Hi,
>
> On Thu, 2008-02-28 at 10:28 +0100, Wouter Cloetens wrote:
> > On Thu, Feb 28, 2008 at 05:23:40PM +0800, Zhao Liang-E3423C wrote:
> > > 1. disable many unused features
> > > 2. disable debug/trace
> > > 3. use binary registry or not use registry 4. disable runtime 
> > > check
> >
> > Has anyone considered statically linking plugins? I suspect that
> would
> > be a rather big change, but you would win on startup time, in memory

> > consumption and in runtime CPU usage.
>
> Most likely, the biggest time consumption in initialization is 
> checking for modifications of plugins (scannning directories, looking 
> at timestamps, loading them if changed, ....).
>
> We *could* add an option to NOT do that scanning at startup (if an 
> environment variable is set when running for example) and just load 
> the available registry.
> In embedded environments you are most likely not installing new 
> plugins very often, so this checking is almost never used but might 
> cost a lot.
>
> You are of course then left with the cost of loading the actual 
> plugins required by the application afterwards, but that's after 
> initialization.
>
> Has anybody done some timing to see how long gst_init() takes ?
>
> Edward
>
> >
> > bfn, Wouter
> >
> >  
> ----------------------------------------------------------------------
> ---
> > This SF.net email is sponsored by: Microsoft Defy all challenges. 
> > Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Gstreamer-embedded mailing list
> > Gstreamer-embedded at li...
> > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
> >
> --
> Edward Hervey <edward.hervey at co...>
> Collabora Multimedia
>>
>

------------------------------------------------------------------------
-
This SF.net email is sponsored by: Microsoft Defy all challenges.
Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Gstreamer-embedded mailing list
Gstreamer-embedded at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded