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:benoit.fouet at purplelabs.com] Sent: Friday, February 29, 2008 5:21 PM To: Zhang Yanlong-PBVM47 Cc: Zhao Liang-E3423C; Nicholas Hannah; gstreamer-embedded at lists.sourceforge.net Subject: Re: 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
