Using playbin2 causes high CPU load on embedded system

[Icarus Alive]

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.