From: Jan S. <th...@no...> - 2008-02-27 20:24:22
|
I'd like to say hi! to the 50 people that have already joined this list, while claiming first post. Now, what did you want to talk about? :) Jan. |
From: Zhao Liang-E. <E3...@mo...> - 2008-02-28 01:06:18
|
Wow, so many people joined this list! congratulation, Jan, you are the first poster! I have some topics want to discuss with guys, I will send mail later, appreciate your reply. thanks Best Regards Zhao Liang -----Original Message----- From: gst...@li... [mailto:gst...@li...] On Behalf Of Jan Schmidt Sent: Thursday, February 28, 2008 4:23 AM To: gst...@li... Subject: [gst-embedded] Welcome! I'd like to say hi! to the 50 people that have already joined this list, while claiming first post. Now, what did you want to talk about? :) Jan. ------------------------------------------------------------------------ - 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 |
From: Zhao Liang-E. <E3...@mo...> - 2008-02-28 01:50:56
|
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. Appreciate for your comments and reply. thanks Best Regards Zhao Liang |
From: Manish R. <man...@gm...> - 2008-02-28 05:55:44
|
Hi Zhao, If you could please tell the methods and options used by you to reduce the size and increase the performance in details. I am also working on the same but could not achieve it to any grate extent. Your inputs can change the way i am trying. Please help. Thanks and Regards Manish Kumar On Thu, Feb 28, 2008 at 7:20 AM, 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. > > Appreciate for your comments and reply. > > thanks > > > Best Regards > Zhao Liang > > ------------------------------------------------------------------------- > 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 > |
From: Zhao Liang-E. <E3...@mo...> - 2008-02-28 09:23:50
|
Manish, As I said in my first mail, I did it 1. disable many unused features 2. disable debug/trace 3. use binary registry or not use registry 4. disable runtime check most of changes are removing unused modules, it can reduce library obviously. gstreamer is flexible and easy configuable, I think you can use configure options or even your own marco to remove your unused. For performance, gstreamer core is just a part of whole performance, and most of it is represented at initialize, such as gst_init(), by my experience, gst_init does all initialization that gstreamer needs, but I think your application may not need all these features. Core elements library is also big, maybe some elements are not needed by yours. Your plugin performance is also very important, I think its impact is bigger than core's. I think gstreamer can be optimized better, if you can share your trying, I think we can do it better. Best Regards Zhao Liang 赵 亮 Tel:86-10-84733698 No.1 Wang Jing East Road, Chao Yang District, Beijing, China 100102 北京市朝阳区望京东路1号, 100102 ________________________________ From: gst...@li... [mailto:gst...@li...] On Behalf Of Manish Rana Sent: Thursday, February 28, 2008 1:56 PM To: Zhao Liang-E3423C Cc: gst...@li... Subject: Re: [gst-embedded] How to reduce gstreamer library size & startuptime Hi Zhao, If you could please tell the methods and options used by you to reduce the size and increase the performance in details. I am also working on the same but could not achieve it to any grate extent. Your inputs can change the way i am trying. Please help. Thanks and Regards Manish Kumar On Thu, Feb 28, 2008 at 7:20 AM, 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. Appreciate for your comments and reply. thanks Best Regards Zhao Liang ------------------------------------------------------------------------- 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 |
From: Wouter C. <wo...@mi...> - 2008-02-28 09:28:47
|
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 |
From: Zhao Liang-E. <E3...@mo...> - 2008-02-28 09:33:11
|
Wouter, 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? Best Regards Zhao Liang -----Original Message----- From: gst...@li... [mailto:gst...@li...] On Behalf Of Wouter Cloetens Sent: Thursday, February 28, 2008 5:29 PM To: gst...@li... Subject: Re: [gst-embedded] How to reduce gstreamer library size& startuptime 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 |
From: Wouter C. <wo...@mi...> - 2008-02-28 09:43:37
|
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. |
From: Edward H. <bi...@gm...> - 2008-02-28 18:36:39
|
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 |
From: Manish R. <man...@gm...> - 2008-02-28 09:46:39
|
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 |
From: Zhao Liang-E. <E3...@mo...> - 2008-02-29 01:51:25
|
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 |
From: Wim T. <wim...@gm...> - 2008-02-29 09:43:54
|
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 |
From: Zhao Liang-E. <E3...@mo...> - 2008-03-03 05:39:45
|
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 |
From: Nie J. <nie...@gm...> - 2008-03-03 03:57:45
|
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 |
From: Zhao Liang-E. <E3...@mo...> - 2008-03-19 06:08:32
|
I have submitted a bug & fix on gst bugillza. http://bugzilla.gnome.org/show_bug.cgi?id=520468 if set GST_REGISTRY_UPDATE as no, initialization will not do scan and update. Best Regards Zhao Liang -----Original Message----- From: Nie Jun [mailto:nie...@gm...] Sent: Monday, March 03, 2008 11:58 AM To: Wim Taymans Cc: Zhao Liang-E3423C; gst...@li... Subject: Re: [gst-embedded] How to reduce gstreamer librarysize & startup time 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 |
From: Gustavo S. B. <bar...@pr...> - 2008-02-29 00:42:14
|
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 |
From: Nicholas H. <nh...@ok...> - 2008-02-29 01:22:47
|
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 >> > |
From: Zhao Liang-E. <E3...@mo...> - 2008-02-29 02:19:44
|
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 |
From: Zhang Yanlong-P. <PB...@mo...> - 2008-02-29 02:59:40
|
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 |
From: Benoit F. <ben...@pu...> - 2008-02-29 09:01:29
|
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 |
From: Zhang Yanlong-P. <PB...@mo...> - 2008-02-29 09:09:26
|
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 |
From: Benoit F. <ben...@pu...> - 2008-02-29 09:21:12
|
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 |
From: Zhang Yanlong-P. <PB...@mo...> - 2008-02-29 09:24:26
|
> >> 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 |
From: Zhao Liang-E. <E3...@mo...> - 2008-02-29 09:28:46
|
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 |