Using playbin2 causes high CPU load on embedded system

[Icarus Alive]

On Tue, Oct 11, 2011 at 6:23 PM, Stefan Sauer <ensonic at hora-obscura.de> wrote:
> 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).
> You could also use the flags property and specify native-audio |
> native-video to forcibly omit the raw-converters.

Already doing that. Remove all typefinds, and have minimap caps
matching, using native audio/video devices and most fundamental
converters.

>> 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.