[Gstreamer-openmax] Gstreamer Pipeline Optimisations ?

[Rob Clark]

On 04/09/2010 06:05 AM, Nitin PAI wrote:
> 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 ?


well, I guess I should say GStreamer *can* be a zero copy framework..  
the framework itself introduces no copies.  But if your display requires 
RGB and the output of your decoder is YUV, then there is no choice but 
to copy (and do a few calculations along the way).  And likewise for 
scaling.

But if the sinkpad and srcpad caps are compatible in the transform 
elements, they will act as just a pass through, so the overhead is 
basically just a couple extra function calls.

(Note that you might also want to look at the flags property on 
playbin2... native-video bit will bypass the video transform elements 
after the decoder before the sink.  If your display hardware supports 
scaling and colorspace conversion, you can optimize your pipeline 
slightly with native-video)


BR,
-R


>
>
> Thanks,
> Nitin
>
>
>
>
>
> On Fri, Apr 9, 2010 at 3:37 PM, Rob Clark <rob at ti.com 
> <mailto:rob at ti.com>> wrote:
>
>     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 <rob at ti.com
>         <mailto:rob at ti.com> <mailto:rob at ti.com <mailto:rob at ti.com>>>
>         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
>
>
>
>
>
> -- 
> “Karmanya vadhikaraste ma phaleshu kadachana Ma karma-phala-hetur bhu 
> ma te sango stav karmani”           -  Krishna