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. Thanks, Nitin <div class="gmail_quote">On Fri, Apr 9, 2010 at 1:29 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><div></div><div class="h5">On 04/09/2010 01:52 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, 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? </blockquote> </div></div> 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 </blockquote></div> -- “Karmanya vadhikaraste ma phaleshu kadachana Ma karma-phala-hetur bhu ma te sango stav karmani” - Krishna