Using playbin2 causes high CPU load on embedded system

[Stefan Sauer]

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.

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