Using playbin2 causes high CPU load on embedded system

[Soeren Grunewald]

Hi All,

	I had a quite similar problem on a tegra2 based system. The cpu usage 
was raising over the time, but also memory usage is growing. After about 
5min of playback the cpu usage exceeds the capabilities of the cpu and 
the stream starts to stuck.

	Using a similar manually created chain (see attached files) does not 
show this behavior.

	I tried various gstreamer versions, to verify that the issue is not 
caused by the omx components i us. But the behavior stays the same. 
Manual chains work perfectly but using playbin(2) or decodebin(2) the 
issue appears.

	In the end i used the manual chain, since my time was limited to work 
on this.
--
Regards
Soeren


On 10/11/2011 12:27 PM, Icarus Alive wrote:
> 2011/10/11 Victor Manuel Jáquez Leal<ceyusa at gmail.com>:
>> On Tue, Oct 11, 2011 at 11:06 AM, stuart68<stuart68 at gmail.com>  wrote:
>>> Hi,
>>>
>>> Can anyone explain why when I change my pipeline to use playbin2 instead of
>>> souphttpsrc, decodebin, queue2, audioconvert, audioresample, alsasink that
>>> my CPU load is noticeably higher.
>>
>> Because playbin2, being constructed at run time depending of how the
>> streams are recognized, would adds more elements on the pipeline than
>> your predefined/optimized pipeline.
>>
>> You can dump a graph of the generated playbin2 pipeline:
>>
>> http://gstreamer.freedesktop.org/wiki/DumpingPipelineGraphs
>>
>> vmjl
>>
>>>
>>> For HD audio formats it is going from around 65% to a constant 99% when
>>> using playbin2.
>>>
>
> BTW, I was able to bring down the CPU utilization of my pipeline, down
> from around 60% to around 25-30% (single CPU in virtualized mode), by
> turning playbin2 into the minimal equivalent with discrete elements,
> however that led to audio/video sync issues. Playbin2 somehow manages
> to keep audio/video sync, but my own pipeline faces issues, when
> erratic network latencies are there (it is a streaming pipeline).
>
> Maybe, someone who has a better understanding of the guts of gstreamer
> and esply how gst-launch works could comment here. IMHO, it is
> sub-optimal if gst-launch has to do any of these *more than once* for
> the pipeline...
> 1. Parse the pipeline description
> 2. Create the pipeline, in-memory (unless OS is doing it, in a way --
> s.a. by swapping due to low free-memory)
> 3. typefind
> 4. capability setting of src/sink pads
> 5. queue allocation/deallocation (i.e. changing queue-size, other than
> just growing to the configured queue-lenght)
>
> If any of those is happening when a pipeline is created
> element-by-element and launched using gst-launch, we are better of
> optimizing it in command-line.
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: playbin2_with_leak.svg
Type: image/svg+xml
Size: 115531 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20111011/c87151da/attachment-0002.svg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: manual_no_leak.svg
Type: image/svg+xml
Size: 51908 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20111011/c87151da/attachment-0003.svg>