Re: [Gstreamer-openmax] Gstreamer Pipeline Optimisations ?

[Rob C. <ro...@ti...>]

On 04/09/2010 03:50 AM, Nitin PAI wrote:
> 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.

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


>
>
> Thanks,
> Nitin
>
> On Fri, Apr 9, 2010 at 1:29 PM, Rob Clark <ro...@ti... 
> <mailto:ro...@ti...>> 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