Hi Rob, Thanks for your input. I enabled the share_input_buffer and share_output_buffer and could see the CPU usage coming down. I was still wondering if Gstreamer is zerocopy considering elements like videobalance/ffmpegcolorspace/videoscale and the queues elements ? Thanks, Nitin <div class="gmail_quote">On Fri, Apr 9, 2010 at 3:37 PM, Rob Clark <<a href="mailto:rob@ti.com">rob@ti.com</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div class="im">On 04/09/2010 03:50 AM, Nitin PAI wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Hi Rob, I see that there are variables like share_input_buffer,share_output_buffer which avoid copying within the gst-openmax wrapper. My question was for the entire gstreamer stack. Considering an application that uses Phonon over Gstreamer (over may be openmax). Are there any optimizations possbile there? Running QT over Phonon, Gstreamer on Embedded devices can kill the cpu for D1 resolutions. </blockquote> </div> I'm not too familiar w/ phonon but GStreamer itself is generally zero copy.. I'm not sure how phonon would introduce a memcpy (assuming it is still using normal gst video sink elements) Take your typical video playback scenario.. gst-openmax will use pad_alloc to allocate a buffer from the display. If share_output_buffer is enabled, this buffer will be passed in to decoder element to decode frame. Zero copies. (Well, assuming you aren't going through xv which introduces a copy no matter what framework you are.. but, for example, omapfbsink or v4l2sink will be zero copy all the way to the display.) I can play 1080p quite nicely through gst-openmax+v4l2sink with low CPU and no memcpy on my little dev board here. BR, -R <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Thanks, Nitin<div class="im"> On Fri, Apr 9, 2010 at 1:29 PM, Rob Clark <<a href="mailto:rob@ti.com" target="_blank">rob@ti.com</a> <mailto:<a href="mailto:rob@ti.com" target="_blank">rob@ti.com</a>>> wrote: On 04/09/2010 01:52 AM, Nitin PAI wrote: Hi, Currently, a typical gstreamer pipeline looks like >gst-launch filesrc location=XYZ ! demuxer ! decodebin ! ffmpegcolorspace ! videobalance ! videoscale ! ximagesink. The movement of data accross is enormous for a D1 or HD resolution as the pipeline passes YUV/RGB data which is very huge. Is there any optimization possible or used which uses *pointers* to pass rather than the huge mem-copies involved? Hi Nitin, search for share_buffer For this to work, it depends on your OpenMAX implementation to support 'non-pre-announced' buffers (which was a recent proposal from Nokia to Khronos standards group) BR, -R -- “Karmanya vadhikaraste ma phaleshu kadachana Ma karma-phala-hetur bhu ma te sango stav karmani” - Krishna </div></blockquote> </blockquote></div> -- “Karmanya vadhikaraste ma phaleshu kadachana Ma karma-phala-hetur bhu ma te sango stav karmani” - Krishna