[Gstreamer-openmax] Gstreamer Pipeline Optimisations ?

[Nitin PAI]

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





On Fri, Apr 9, 2010 at 3:37 PM, Rob Clark <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>>
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-openmax/attachments/20100409/ac0ca15e/attachment.htm>