[gst-devel] GStreamer performance On the embedded platform

[ye nan]

I used the --disable-gst-debug, and also append "--disable-loadsave 
--disable-registry --disable-gst-debug" to the configure command line. 
Without the registry mechanism, We load plugins maunlly by using 
gst_plugin_load_file() in our own test applications. This can short the 
duration of the GStreamer application starting.
As you say, we also met some memory problem with GStreamer especailly when 
we attempt to use some plugins contained in gst-plugin-good package. The 
element "osssink" can not work properly in our demo platform, and even make 
for a "segment fault" when we use gst-inspect to look round the details. 
But we test mad and wavenc plugins instead, they can work correctly.
Nevertheless, I think the binary size of GStreamer fits our requirement at 
the present time and I am convince it can be an excellent framework also in 
the embedded system. We will try to solve the problems and optmize its 
performance on our platfrom.

Thanks

Bucket

>From: David Schleef <ds at schleef.org>
>To: ye nan <bucketxp at hotmail.com>
>CC: gstreamer-devel at lists.sourceforge.net
>Subject: Re: [gst-devel] GStreamer performance On the embedded platform
>Date: Tue, 31 Jan 2006 23:08:05 -0800
>
>On Wed, Feb 01, 2006 at 01:33:11PM +0800, ye nan wrote:
> > The application uses a video sink "xiamgesink" to dispaly only the 
video
> > stream in a mpeg2 stream with the libmpeg2 decoder plugin in
> > gst-plugin-ugly package. But I think its performance is not good as I
> > thought. It is slower than the applications which use the libmpeg 
directly,
> > such as mpeg2dec or mplayer.
> > The nokida 770 used the Gstreamer, and it's basic configuration is OMAP
> > 192HMz cpu with 64M memory. Our demo platform is 200MHz cpu with 64M
> > memory. The run-time performance of GStreamer on our platform can not 
make
> > our satisfied.So we want to know is that the limition of GStreamer 
itself
> > or just the limitaton of codec plugins?
> > Our test is basing on the Gstreamer 0.10.0 and corresponding plugins
> > packages. We test the performance both our own application and the
> > gst-launch command line:
> > gst-launch filesrc location=<test.mpg> ! mpegdemux name=demuxer
> > demuxer.video_00 ! mpeg2dec ! ffmpegcolorspace ! ximagesink
>
>The very first thing you want to do when examining the performace or
>size of GStreamer for an embedded system is turn off the internal
>debugging code using ./configure --disable-gst-debug.  There's other
>stuff you might want to turn off, but they're less important.
>
>The overhead of GStreamer is going to be very minor compared to the
>CPU requirements of decoding a video stream in software.  A few
>percent for a lightweight stream (mp3 decoding, for example), and
>less for anything heavier like decoding video.  If you notice anything
>significantly larger, it's probably a bug.
>
>Two notable problems that relate to embedded systems currently:
>
>  - GStreamer often exposes a bug in glibc's memory allocator that
>    can cause repeated mmap()/munmap()s of large chunks of memory,
>    causing lots of unnecessary page faults and page clearing in
>    the kernel.
>
>  - For unknown reasons, flex generates a 2 MB source file to parse
>    GStreamer launch lines, which compiles into a ~650 kB .o file
>    on i386.  This is insane.
>
>
>
>dave...
>
>--
>David Schleef
>Big Kitten LLC (http://www.bigkitten.com/) -- data acquisition on Linux

_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger:  http://messenger.msn.com/cn