gstreamer-embedded — GStreamer on embedded platforms

Re: [gst-embedded] How to use DSP in gstreamer

[Zhao Liang-E. <E3...@mo...>]

On Tue, 2008-03-04 at 10:10 +0800, ext Zhang Yanlong-PBVM47 wrote:
> Yes, I think it is not a simple things if integrate gstreamer with 
> other hardware, e.g dsp.
> Maybe implement a set of API in dsp side and provide it to gstreamer 
> is a good solution.
> 
> BRs
> Zhang
> 
> -----Original Message-----
> From: gst...@li...
> [mailto:gst...@li...] On Behalf Of

> Zhao Liang-E3423C
> Sent: Tuesday, March 04, 2008 10:05 AM
> To: Benoit Fouet
> Cc: gst...@li...
> Subject: Re: [gst-embedded] How to use DSP in gstreamer
> 
> 
> Hi,
> 
> Zhao Liang-E3423C wrote:
> > Zhao Liang-E3423C wrote:
> >   
> >> Hi all,
> >>  
> >> On embedded device, DSP is used widely, many DSPs have different 
> >> features, for example:
> >>  
> >> 1. decoder
> >> DSP is just a hardware decoder
> >> 2. decoder + sink
> >> DSP is a decoder plus sink, it can directly accept encoded data, 
> >> and then decode it and render pcm data into audio device directly.
> >>     
> >
> > creating a sink with right caps should be enough for this one...
> >
> > Zhao Liang:  By my experience, it is not simple like just adding a 
> > new
> 
> > caps.
> > 		Just  a example, how to handle preroll? Generally, dsp
> need to do
> > initialization when start to work, so what is the time to do this?
> > 		another issue is seek, how does DSP handle seek?	
> >
> >   
> 
> >this is generally the demuxer/parser's job to handle seek, do you 
> >have
> examples where it is up to the decoder to do it ?
> 
> As it is a sink for DSP although it includes decoder functions, sink 
> would handle preroll, in current preroll mechanism, it only allows 
> sink do once preroll virtual function, all other buffers are pushed 
> into queue, but some hardwares need more buffers to do initialization.
> 
> Another issue is if the DSP is audio decoder + sink, how to handle 
> clock line increasing? Currently, we can use gstaudiosink to do it, 
> gstringbuffer can handle all clock line increasing, but some DSP can 
> not do it if no data is fed into, so the clock calculation is really a

> issue. If no mechanism, rtsp streaming application will not handle 
> buffer delay or lost.
> 
> 
> >> 3. A/V sync
> >> DSP can do A/V sync internally or not.
> >>     
> >
> > then you can ask basesink not to synchronize flows.
> >
> > Zhao Liang: If DSP is just a video decoder and sink, how does DSP 
> > sync
> 
> > with audio sink? maybe current basesink considers more software sink

> > than hardware sink.
> >
> >   
> 
> >I was talking about your hardware handling A/V synchronization, not 
> >the
> opposite.
> >buffers that are handled by sink are timestamped (by demuxers for
> >instance) and are rightly handled by basesink when synchronization 
> >has
> to be done in framework, and not in HW.
> 
> I understood your meaning, A/V sync is really done by basesink, but 
> some DSPs also have internal buffers to store buffers synced. and 
> these synced buffers are encoded buffers, not raw buffers.
> There are  4 combinations:
> 1. DSP videosink  v.s  software audiosink 2. DSP videosink  v.s  DSP 
> audiosink 3. software videosink  v.s  DSP audiosink 4. software 
> videosink  v.s  software audiosink

> When there's a decoder+sink, one approach is to map the hw clock to
the GStreamer clock, that way synchronization is still handled by
GStreamer transparently.

> However, I would like to see some numbers regarding the performance
improvement when doing such thing (decoder+sink), I wonder if it's worth
the trouble.

It is a good ideal to wrap hw clock to gstclock. For decoder+sink,
sometimes it is restricted by HW, I saw nokia N800 using DSP gateway as
audio sink, by my understanding, is it a decoder+sink? If you can share
some experience on it, it will be appreciated.


> Best regards.

--
> Felipe Contreras


------------------------------------------------------------------------
-
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
Gst...@li...
https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded

Re: [gst-embedded] How to use DSP in gstreamer

[Felipe C. <fel...@no...>]

On Tue, 2008-03-04 at 10:10 +0800, ext Zhang Yanlong-PBVM47 wrote:
> Yes, I think it is not a simple things if integrate gstreamer with other
> hardware, e.g dsp.
> Maybe implement a set of API in dsp side and provide it to gstreamer is
> a good solution.
> 
> BRs
> Zhang
> 
> -----Original Message-----
> From: gst...@li...
> [mailto:gst...@li...] On Behalf Of
> Zhao Liang-E3423C
> Sent: Tuesday, March 04, 2008 10:05 AM
> To: Benoit Fouet
> Cc: gst...@li...
> Subject: Re: [gst-embedded] How to use DSP in gstreamer
> 
> 
> Hi,
> 
> Zhao Liang-E3423C wrote:
> > Zhao Liang-E3423C wrote:
> >   
> >> Hi all,
> >>  
> >> On embedded device, DSP is used widely, many DSPs have different 
> >> features, for example:
> >>  
> >> 1. decoder
> >> DSP is just a hardware decoder
> >> 2. decoder + sink
> >> DSP is a decoder plus sink, it can directly accept encoded data, and 
> >> then decode it and render pcm data into audio device directly.
> >>     
> >
> > creating a sink with right caps should be enough for this one...
> >
> > Zhao Liang:  By my experience, it is not simple like just adding a new
> 
> > caps.
> > 		Just  a example, how to handle preroll? Generally, dsp
> need to do 
> > initialization when start to work, so what is the time to do this?
> > 		another issue is seek, how does DSP handle seek?	
> >
> >   
> 
> >this is generally the demuxer/parser's job to handle seek, do you have
> examples where it is up to the decoder to do it ?
> 
> As it is a sink for DSP although it includes decoder functions, sink
> would handle preroll, in current preroll mechanism, it only allows sink
> do once preroll virtual function, all other buffers are pushed into
> queue, but some hardwares need more buffers to do initialization.
> 
> Another issue is if the DSP is audio decoder + sink, how to handle clock
> line increasing? Currently, we can use gstaudiosink to do it,
> gstringbuffer can handle all clock line increasing, but some DSP can not
> do it if no data is fed into, so the clock calculation is really a
> issue. If no mechanism, rtsp streaming application will not handle
> buffer delay or lost.
> 
> 
> >> 3. A/V sync
> >> DSP can do A/V sync internally or not.
> >>     
> >
> > then you can ask basesink not to synchronize flows.
> >
> > Zhao Liang: If DSP is just a video decoder and sink, how does DSP sync
> 
> > with audio sink? maybe current basesink considers more software sink 
> > than hardware sink.
> >
> >   
> 
> >I was talking about your hardware handling A/V synchronization, not the
> opposite.
> >buffers that are handled by sink are timestamped (by demuxers for
> >instance) and are rightly handled by basesink when synchronization has
> to be done in framework, and not in HW.
> 
> I understood your meaning, A/V sync is really done by basesink, but some
> DSPs also have internal buffers to store buffers synced. and these
> synced buffers are encoded buffers, not raw buffers. 
> There are  4 combinations:
> 1. DSP videosink  v.s  software audiosink 2. DSP videosink  v.s  DSP
> audiosink 3. software videosink  v.s  DSP audiosink 4. software
> videosink  v.s  software audiosink

When there's a decoder+sink, one approach is to map the hw clock to the
GStreamer clock, that way synchronization is still handled by GStreamer
transparently.

However, I would like to see some numbers regarding the performance
improvement when doing such thing (decoder+sink), I wonder if it's worth
the trouble.

Best regards.

-- 
Felipe Contreras

Re: [gst-embedded] How to use DSP in gstreamer

[Zhang Yanlong-P. <PB...@mo...>]

Yes, I think it is not a simple things if integrate gstreamer with other
hardware, e.g dsp.
Maybe implement a set of API in dsp side and provide it to gstreamer is
a good solution.

BRs
Zhang

-----Original Message-----
From: gst...@li...
[mailto:gst...@li...] On Behalf Of
Zhao Liang-E3423C
Sent: Tuesday, March 04, 2008 10:05 AM
To: Benoit Fouet
Cc: gst...@li...
Subject: Re: [gst-embedded] How to use DSP in gstreamer


Hi,

Zhao Liang-E3423C wrote:
> Zhao Liang-E3423C wrote:
>   
>> Hi all,
>>  
>> On embedded device, DSP is used widely, many DSPs have different 
>> features, for example:
>>  
>> 1. decoder
>> DSP is just a hardware decoder
>> 2. decoder + sink
>> DSP is a decoder plus sink, it can directly accept encoded data, and 
>> then decode it and render pcm data into audio device directly.
>>     
>
> creating a sink with right caps should be enough for this one...
>
> Zhao Liang:  By my experience, it is not simple like just adding a new

> caps.
> 		Just  a example, how to handle preroll? Generally, dsp
need to do 
> initialization when start to work, so what is the time to do this?
> 		another issue is seek, how does DSP handle seek?	
>
>   

>this is generally the demuxer/parser's job to handle seek, do you have
examples where it is up to the decoder to do it ?

As it is a sink for DSP although it includes decoder functions, sink
would handle preroll, in current preroll mechanism, it only allows sink
do once preroll virtual function, all other buffers are pushed into
queue, but some hardwares need more buffers to do initialization.

Another issue is if the DSP is audio decoder + sink, how to handle clock
line increasing? Currently, we can use gstaudiosink to do it,
gstringbuffer can handle all clock line increasing, but some DSP can not
do it if no data is fed into, so the clock calculation is really a
issue. If no mechanism, rtsp streaming application will not handle
buffer delay or lost.


>> 3. A/V sync
>> DSP can do A/V sync internally or not.
>>     
>
> then you can ask basesink not to synchronize flows.
>
> Zhao Liang: If DSP is just a video decoder and sink, how does DSP sync

> with audio sink? maybe current basesink considers more software sink 
> than hardware sink.
>
>   

>I was talking about your hardware handling A/V synchronization, not the
opposite.
>buffers that are handled by sink are timestamped (by demuxers for
>instance) and are rightly handled by basesink when synchronization has
to be done in framework, and not in HW.

I understood your meaning, A/V sync is really done by basesink, but some
DSPs also have internal buffers to store buffers synced. and these
synced buffers are encoded buffers, not raw buffers. 
There are  4 combinations:
1. DSP videosink  v.s  software audiosink 2. DSP videosink  v.s  DSP
audiosink 3. software videosink  v.s  DSP audiosink 4. software
videosink  v.s  software audiosink

How to sync a/v with encoded buffers? It  really puzzled me. openmax can
do it well for some cases, as it has a clock in itself.  but by my
understanding, basesink is used to sync decoded buffers.  Appreicate for
your clarifying.


--
Benoit Fouet
Purple Labs S.A.
www.purplelabs.com

------------------------------------------------------------------------
-
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
Gst...@li...
https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded

Re: [gst-embedded] How to use DSP in gstreamer

[Zhao Liang-E. <E3...@mo...>]

Hi,

Zhao Liang-E3423C wrote:
> Zhao Liang-E3423C wrote:
>   
>> Hi all,
>>  
>> On embedded device, DSP is used widely, many DSPs have different 
>> features, for example:
>>  
>> 1. decoder
>> DSP is just a hardware decoder
>> 2. decoder + sink
>> DSP is a decoder plus sink, it can directly accept encoded data, and 
>> then decode it and render pcm data into audio device directly.
>>     
>
> creating a sink with right caps should be enough for this one...
>
> Zhao Liang:  By my experience, it is not simple like just adding a new

> caps.
> 		Just  a example, how to handle preroll? Generally, dsp
need to do 
> initialization when start to work, so what is the time to do this?
> 		another issue is seek, how does DSP handle seek?	
>
>   

>this is generally the demuxer/parser's job to handle seek, do you have
examples where it is up to the decoder to do it ?

As it is a sink for DSP although it includes decoder functions, sink
would handle preroll, in current preroll mechanism, it only allows sink
do once preroll virtual function, all other buffers are pushed into
queue, but some hardwares need more buffers to do initialization.

Another issue is if the DSP is audio decoder + sink, how to handle clock
line increasing? Currently, we can use gstaudiosink to do it,
gstringbuffer can handle all clock line increasing, but some DSP can not
do it if no data is fed into, so the clock calculation is really a
issue. If no mechanism, rtsp streaming application will not handle
buffer delay or lost.


>> 3. A/V sync
>> DSP can do A/V sync internally or not.
>>     
>
> then you can ask basesink not to synchronize flows.
>
> Zhao Liang: If DSP is just a video decoder and sink, how does DSP sync

> with audio sink? maybe current basesink considers more software sink 
> than hardware sink.
>
>   

>I was talking about your hardware handling A/V synchronization, not the
opposite.
>buffers that are handled by sink are timestamped (by demuxers for
>instance) and are rightly handled by basesink when synchronization has
to be done in framework, and not in HW.

I understood your meaning, A/V sync is really done by basesink, but some
DSPs also have internal buffers to store buffers synced. and these
synced buffers are encoded buffers, not raw buffers. 
There are  4 combinations:
1. DSP videosink  v.s  software audiosink
2. DSP videosink  v.s  DSP audiosink
3. software videosink  v.s  DSP audiosink
4. software videosink  v.s  software audiosink

How to sync a/v with encoded buffers? It  really puzzled me. openmax can
do it well for some cases, as it has a clock in itself.  but by my
understanding, basesink is used to sync decoded buffers.  Appreicate for
your clarifying.


--
Benoit Fouet
Purple Labs S.A.
www.purplelabs.com

Re: [gst-embedded] How to use DSP in gstreamer

[Benoit F. <ben...@pu...>]

Hi,

Zhao Liang-E3423C wrote:
> Zhao Liang-E3423C wrote:
>   
>> Hi all,
>>  
>> On embedded device, DSP is used widely, many DSPs have different 
>> features, for example:
>>  
>> 1. decoder
>> DSP is just a hardware decoder
>> 2. decoder + sink
>> DSP is a decoder plus sink, it can directly accept encoded data, and 
>> then decode it and render pcm data into audio device directly.
>>     
>
> creating a sink with right caps should be enough for this one...
>
> Zhao Liang:  By my experience, it is not simple like just adding a new
> caps. 
> 		Just  a example, how to handle preroll? Generally, dsp
> need to do initialization when start to work, so what is the time to do
> this? 
> 		another issue is seek, how does DSP handle seek?	
>
>   

this is generally the demuxer/parser's job to handle seek, do you have
examples where it is up to the decoder to do it ?

>> 3. A/V sync
>> DSP can do A/V sync internally or not.
>>     
>
> then you can ask basesink not to synchronize flows.
>
> Zhao Liang: If DSP is just a video decoder and sink, how does DSP sync
> with audio sink? maybe current basesink considers more software sink
> than hardware sink.
>
>   

I was talking about your hardware handling A/V synchronization, not the
opposite.
buffers that are handled by sink are timestamped (by demuxers for
instance) and are rightly handled by basesink when synchronization has
to be done in framework, and not in HW.

-- 
Benoit Fouet
Purple Labs S.A.
www.purplelabs.com

Re: [gst-embedded] How to use DSP in gstreamer

[Yann G. <yan...@pu...>]

Hi Zhao,

Zhao Liang-E3423C wrote:
> Zhao Liang-E3423C wrote:
>>
>> 2. decoder + sink
>> DSP is a decoder plus sink, it can directly accept encoded data, and 
>> then decode it and render pcm data into audio device directly.
>>     
>
> creating a sink with right caps should be enough for this one...
>
> Zhao Liang:  By my experience, it is not simple like just adding a new
> caps. 
> 		Just  a example, how to handle preroll? Generally, dsp
> need to do initialization when start to work, so what is the time to do
> this? 
>   

you can add your sink into the pipeline but not link its sink pad
immediatly when creating it.
Your sink element could post a message on the pipeline bus to notify
it's ready when it happens, and then you link it to allow preroll.

-- 
Yann Gilquin

Purple Labs S.A.
www.purplelabs.com

Re: [gst-embedded] How to use DSP in gstreamer

[Zhao Liang-E. <E3...@mo...>]

Zhao Liang-E3423C wrote:
> Hi all,
>  
> On embedded device, DSP is used widely, many DSPs have different 
> features, for example:
>  
> 1. decoder
> DSP is just a hardware decoder
> 2. decoder + sink
> DSP is a decoder plus sink, it can directly accept encoded data, and 
> then decode it and render pcm data into audio device directly.

creating a sink with right caps should be enough for this one...

Zhao Liang:  By my experience, it is not simple like just adding a new
caps. 
		Just  a example, how to handle preroll? Generally, dsp
need to do initialization when start to work, so what is the time to do
this? 
		another issue is seek, how does DSP handle seek?	

> 3. A/V sync
> DSP can do A/V sync internally or not.

then you can ask basesink not to synchronize flows.

Zhao Liang: If DSP is just a video decoder and sink, how does DSP sync
with audio sink? maybe current basesink considers more software sink
than hardware sink.

>  
> There may be more features i don't list. For these features, how can 
> we implement them by gstreamer?
>  
> For case 1, I think it is esay to do by gstreamer, but for each 2 and 
> 3, it seems gstreamer has no available resources to define these 
> application. So I think we can discuss these topics and find a good 
> solution.
>  
> BTW, I find a project in gst - "gst-openmax", it is using openmax as 
> low level implementation, but it also has some limitation, for 
> example, no solution for case 2, and we must have openmax 
> implementation for special DSP firstly.
>  
> I hope we can have top level solution for DSP in despite of the low 
> level implementation, just link gstbasesink virtual class, but all 
> interfaces or virtual functions are defined to handle all the use
cases.

--
Benoit Fouet
Purple Labs S.A.
www.purplelabs.com

Re: [gst-embedded] How to use DSP in gstreamer

[Benoit F. <ben...@pu...>]

Hi,

Zhao Liang-E3423C wrote:
> Hi all,
>  
> On embedded device, DSP is used widely, many DSPs have different
> features, for example:
>  
> 1. decoder
> DSP is just a hardware decoder
> 2. decoder + sink
> DSP is a decoder plus sink, it can directly accept encoded data, and
> then decode it and render pcm data into audio device directly.

creating a sink with right caps should be enough for this one...

> 3. A/V sync
> DSP can do A/V sync internally or not.

then you can ask basesink not to synchronize flows.

>  
> There may be more features i don't list. For these features, how can
> we implement them by gstreamer?
>  
> For case 1, I think it is esay to do by gstreamer, but for each 2 and
> 3, it seems gstreamer has no available resources to define these
> application. So I think we can discuss these topics and find a good
> solution.
>  
> BTW, I find a project in gst - "gst-openmax", it is using openmax as
> low level implementation, but it also has some limitation, for
> example, no solution for case 2, and we must have openmax
> implementation for special DSP firstly.
>  
> I hope we can have top level solution for DSP in despite of the low
> level implementation, just link gstbasesink virtual class, but all
> interfaces or virtual functions are defined to handle all the use cases.

-- 
Benoit Fouet
Purple Labs S.A.
www.purplelabs.com

[gst-embedded] How to use DSP in gstreamer

[Zhao Liang-E. <E3...@mo...>]

Hi all,
 
On embedded device, DSP is used widely, many DSPs have different
features, for example:
 
1. decoder
DSP is just a hardware decoder
2. decoder + sink
DSP is a decoder plus sink, it can directly accept encoded data, and
then decode it and render pcm data into audio device directly.
3. A/V sync
DSP can do A/V sync internally or not.
 
There may be more features i don't list. For these features, how can we
implement them by gstreamer?
 
For case 1, I think it is esay to do by gstreamer, but for each 2 and 3,
it seems gstreamer has no available resources to define these
application. So I think we can discuss these topics and find a good
solution.
 
BTW, I find a project in gst - "gst-openmax", it is using openmax as low
level implementation, but it also has some limitation, for example, no
solution for case 2, and we must have openmax implementation for special
DSP firstly.
 
I hope we can have top level solution for DSP in despite of the low
level implementation, just link gstbasesink virtual class, but all
interfaces or virtual functions are defined to handle all the use cases.
 

Best Regards
Zhao Liang

 

 

Re: [gst-embedded] How to reduce gstreamer librarysize & startuptime

[Zhao Liang-E. <E3...@mo...>]

Wim,

In my opinion,  not all applications are using
"gst_type_find_factory_get_type" and  "_gst_query_initialize",  just
like "gst_index_factory_get_type", it is included by a marco
"GST_DISABLE_INDEX".

type_find is used to detect file format, but it can also be done in
demuxer,  gst_query is used to query interface from element, but if user
don't want to use this feature, it will be redundant. It is just gotten
from my experience, maybe not for other users.

Best Regards
Zhao Liang 
 

-----Original Message-----
From: Wim Taymans [mailto:wim...@gm...] 
Sent: Friday, February 29, 2008 5:47 PM
To: Zhao Liang-E3423C
Cc: gst...@li...
Subject: Re: [gst-embedded] How to reduce gstreamer librarysize &
startuptime

On Fri, 2008-02-29 at 09:39 +0800, Zhao Liang-E3423C wrote:
> Edward,
> 
> I have done as you said,  scanning and updating the registry is really

> "cost-time",  after removing it by hard code, it saves much time.
> 
> But I wonder whether all object initialization in gst_init are all 
> necessary,  I think it will be better if gstreamer can provide more 
> options to disable/enable features, so that user can reduce 
> unnecessary modules easily.

What object initialisation are you refering to? What more things do you
want to be able to disable?

Wim

> 
> 
> Best Regards
> Zhao Liang
>  
> 
> -----Original Message-----
> From: gst...@li...
> [mailto:gst...@li...] On Behalf Of

> Edward Hervey
> Sent: Friday, February 29, 2008 4:35 AM
> To: Wouter Cloetens
> Cc: gst...@li...
> Subject: Re: [gst-embedded] How to reduce gstreamer librarysize & 
> startuptime
> 
> 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
> > Gst...@li...
> > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
> > 
> --
> Edward Hervey <edw...@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
> Gst...@li...
> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
> 
> ----------------------------------------------------------------------
> --- 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
> Gst...@li...
> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded

Re: [gst-embedded] How to reduce gstreamer librarysize & startup time

[Nie J. <nie...@gm...>]

If an option can support choosing scanning and updating on request, instead of every initialization, for example,  just done in gst-inspect, I believe initialization will cost much less time.

2008/2/29, Wim Taymans <wim...@gm...>:
On Fri, 2008-02-29 at 09:39 +0800, Zhao Liang-E3423C wrote:
> Edward,
>
> I have done as you said,  scanning and updating the registry is really
> "cost-time",  after removing it by hard code, it saves much time.
>
> But I wonder whether all object initialization in gst_init are all
> necessary,  I think it will be better if gstreamer can provide more
> options to disable/enable features, so that user can reduce unnecessary
> modules easily.
What object initialisation are you refering to? What more things do you
want to be able to disable?
Wim
>
>
> Best Regards
> Zhao Liang
>
>
> -----Original Message-----
> From: gst...@li...
> [mailto:gst...@li...] On Behalf Of
> Edward Hervey
> Sent: Friday, February 29, 2008 4:35 AM
> To: Wouter Cloetens
> Cc: gst...@li...
> Subject: Re: [gst-embedded] How to reduce gstreamer librarysize &
> startuptime
>
> 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
> > Gst...@li...
> > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
> >
> --
> Edward Hervey <edw...@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
> Gst...@li...
> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
>
> -------------------------------------------------------------------------
> 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
> Gst...@li...
> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
-------------------------------------------------------------------------
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
Gst...@li...
https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded

Re: [gst-embedded] How to reduce gstreamer librarysize & startup time

[Wim T. <wim...@gm...>]

On Fri, 2008-02-29 at 09:39 +0800, Zhao Liang-E3423C wrote:
> Edward,
> 
> I have done as you said,  scanning and updating the registry is really
> "cost-time",  after removing it by hard code, it saves much time.
> 
> But I wonder whether all object initialization in gst_init are all
> necessary,  I think it will be better if gstreamer can provide more
> options to disable/enable features, so that user can reduce unnecessary
> modules easily.

What object initialisation are you refering to? What more things do you
want to be able to disable?

Wim

> 
> 
> Best Regards
> Zhao Liang
>  
> 
> -----Original Message-----
> From: gst...@li...
> [mailto:gst...@li...] On Behalf Of
> Edward Hervey
> Sent: Friday, February 29, 2008 4:35 AM
> To: Wouter Cloetens
> Cc: gst...@li...
> Subject: Re: [gst-embedded] How to reduce gstreamer librarysize &
> startuptime
> 
> 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
> > Gst...@li...
> > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
> > 
> --
> Edward Hervey <edw...@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
> Gst...@li...
> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
> 
> -------------------------------------------------------------------------
> 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
> Gst...@li...
> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded

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

[Zhao Liang-E. <E3...@mo...>]

Benoit,

gst_pad_alloc_buffer() allows downstreame element have chance to manage
the memory allocation. 
For example, when decoder finishes decode, it will allocate buffer to
store data and push to sink, and release it after sink to audio device ,
but if use gst_pad_alloc_buffer(), audiosink can allocate memory in
audio device as buffer, and decoder should not allocate and release it
repeatedly. 

It will save system memory allocation time.

gst_buffer_new() can also do it, but it is using glib memory pool, not
memory in device.

Best Regards
Zhao Liang
 

-----Original Message-----
From: Benoit Fouet [mailto:ben...@pu...] 
Sent: Friday, February 29, 2008 5:21 PM
To: Zhang Yanlong-PBVM47
Cc: Zhao Liang-E3423C; Nicholas Hannah;
gst...@li...
Subject: Re: [gst-embedded] How to reduce gstreamer library size
&startuptime

Hi,

Zhang Yanlong-PBVM47 wrote:
>  
>   
>> 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.
>
>   

this can also work if you're doing a gst_buffer_new(), and not a
gst_buffer_new_and_alloc(), I don't really see a difference here...
the data you're providing to downstream element doesn't have to be
memcpy'd, it can be a pointer to a buffer of data in your element.

--
Benoit Fouet
Purple Labs S.A.
www.purplelabs.com

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

[Zhang Yanlong-P. <PB...@mo...>]

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

>this can also work if you're doing a gst_buffer_new(), and not a
gst_buffer_new_and_alloc(), I don't really see a difference here...
>the data you're providing to downstream element doesn't have to be
memcpy'd, it can be a pointer to a buffer of data in your element.

It is just an example for optimization, I do not mean that you must
replace by it. Whether or not using it depends on your implementation.

--
Benoit Fouet
Purple Labs S.A.
www.purplelabs.com

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

[Benoit F. <ben...@pu...>]

Hi,

Zhang Yanlong-PBVM47 wrote:
>  
>   
>> 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.
>
>   

this can also work if you're doing a gst_buffer_new(), and not a
gst_buffer_new_and_alloc(), I don't really see a difference here...
the data you're providing to downstream element doesn't have to be
memcpy'd, it can be a pointer to a buffer of data in your element.

-- 
Benoit Fouet
Purple Labs S.A.
www.purplelabs.com

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

[Zhang Yanlong-P. <PB...@mo...>]

 
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: gst...@li...
> [mailto:gst...@li...] On Behalf Of

> Nicholas Hannah
> Sent: Friday, February 29, 2008 9:23 AM
> To: gst...@li...
> 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.
>
>   

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

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

[Benoit F. <ben...@pu...>]

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: gst...@li...
> [mailto:gst...@li...] On Behalf Of
> Nicholas Hannah
> Sent: Friday, February 29, 2008 9:23 AM
> To: gst...@li...
> 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.
>
>   

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

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

[Zhang Yanlong-P. <PB...@mo...>]

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.

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.

Anyway, more verification on real environment is needed.

BRs
Zhang 

-----Original Message-----
From: gst...@li...
[mailto:gst...@li...] On Behalf Of
Zhao Liang-E3423C
Sent: Friday, February 29, 2008 9:48 AM
To: Nicholas Hannah; gst...@li...
Subject: Re: [gst-embedded] How to reduce gstreamer library size
&startuptime

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: gst...@li...
[mailto:gst...@li...] On Behalf Of
Nicholas Hannah
Sent: Friday, February 29, 2008 9:23 AM
To: gst...@li...
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@li...
> > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
> >
> --
> Edward Hervey <edward.hervey@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
Gst...@li...
https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded

------------------------------------------------------------------------
-
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
Gst...@li...
https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded

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

[Zhao Liang-E. <E3...@mo...>]

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: gst...@li...
[mailto:gst...@li...] On Behalf Of
Nicholas Hannah
Sent: Friday, February 29, 2008 9:23 AM
To: gst...@li...
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@li...
> > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
> >
> --
> Edward Hervey <edward.hervey@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
Gst...@li...
https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded

Re: [gst-embedded] How to reduce gstreamer librarysize & startup time

[Zhao Liang-E. <E3...@mo...>]

 
Edward,

I have done as you said,  scanning and updating the registry is really
"cost-time",  after removing it by hard code, it saves much time.

But I wonder whether all object initialization in gst_init are all
necessary,  I think it will be better if gstreamer can provide more
options to disable/enable features, so that user can reduce unnecessary
modules easily.


Best Regards
Zhao Liang
 

-----Original Message-----
From: gst...@li...
[mailto:gst...@li...] On Behalf Of
Edward Hervey
Sent: Friday, February 29, 2008 4:35 AM
To: Wouter Cloetens
Cc: gst...@li...
Subject: Re: [gst-embedded] How to reduce gstreamer librarysize &
startuptime

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
> Gst...@li...
> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
> 
--
Edward Hervey <edw...@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
Gst...@li...
https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded

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

[Nicholas H. <nh...@ok...>]

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@li...
> > https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
> >
> -- 
> Edward Hervey <edward.hervey@co...>
> Collabora Multimedia
>>
>

Re: [gst-embedded] How to reduce gstreamer library size & startup time

[Gustavo S. B. <bar...@pr...>]

On Wed, Feb 27, 2008 at 10:50 PM, Zhao Liang-E3423C <E3...@mo...> wrote:
> Hi all,
>
>  As I am working on embedded device, my device has low cpu power, but  I
>  want to develop some applications, such as ringtone, which needs to
>  launch gstreamer quickly.
>  I find if we don't do any library cutting down, the gstreamer core
>  library is big, about 700-800 KB, but that will not match my
>  requirement, the time cost on loading library is long.
>  Another issue is that gst_init() cost much time.
>
>  So my goal is to make the best of  reducing gstreamer library size and
>  gst_init() time.
>
>  For library size cutting down, I have tried some ways, such as
>  1. disable many unused features
>  2. disable debug
>  3, not use xml registry etc
>  at last, the core library size is about 350KB
>
>  For gst_init(), I also did some tunning on startup options, such as
>  "disable option parsing" etc.
>
>  But I think it is not the best that gstreamer can reach, maybe there are
>  many other ways to do these, so if we can share our experience, I think
>  we can get better result.

http://blog.flameeyes.eu/articles/2008/01/17/today-how-to-identify-unused-exported-functions-and-variables

provides some hints on how to detect unused functions and globals,
this might help. Don't expect huge winnings because gstreamer is
already good, but it will cost you almost nothing to check...  If you
find something, then let us know.

As Edward said in a latter message to this thread, measuring/profiling
gst_init() will help.


-- 
Gustavo Sverzut Barbieri
http://profusion.mobi - Embedded and Mobile Software Development
--------------------------------------
MSN: bar...@gm...
Skype: gsbarbieri
Mobile: +55 (81) 9927 0010

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

[Edward H. <bi...@gm...>]

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
> Gst...@li...
> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
> 
-- 
Edward Hervey <edw...@co...>
Collabora Multimedia

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

[Manish R. <man...@gm...>]

hi Wouter,
In that case you will  have to write application for each type e.g. in case
of video one for MPEG4 and 1 for H263 and so on..... :'(
and how to manage them then......??
how about using gst_plugin_load_file ??
how efficient this will be ?

On Thu, Feb 28, 2008 at 2:58 PM, Wouter Cloetens <wo...@mi...> 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.
>
> 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
> Gst...@li...
> https://lists.sourceforge.net/lists/listinfo/gstreamer-embedded
>



-- 
Manish Rana
Software Engg.
Handset Technology Solution,
Sasken Comm. Tech.
Bangalore,India

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

[Wouter C. <wo...@mi...>]

If indeed there is only one application, you'd have to worry about its
licence as if you'd be statically linking it with LGPL code. If that's
acceptable, then great.
But what I was thinking of is making the whole of gstreamer, with all
the required plugins, into one shared library.

bfn, Wouter

On Thu, Feb 28, 2008 at 05:32:59PM +0800, Zhao Liang-E3423C wrote:
> I think it is really a good idea if only one application is using
> gstreamer,  if these plugins are shared for all applications, how can we
> do?

> From: gst...@li...
> [mailto:gst...@li...] On Behalf Of
> Wouter Cloetens
> Sent: Thursday, February 28, 2008 5:29 PM

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