• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 913 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

GStreamer pipelines have widely varying CPU load

Ian Willats
Prodigy 250 points

Hello,

I am seeing strange behaviour of several GStreamer pipelines running on a DM368 (LeopardBoard).  In a nutshell, the CPU load reported by the dmaiperf plug-in (and verified by top) will vary between two limiting values, for example 1%-25% or 15%-50% depending on the pipeline.  In some cases the pipeline will "stick" in one mode, then after an unpredictable time it will switch to the other mode.  In other cases the pipeline will flip back and forth between the two modes over a period of several seconds or minutes.  The transition is more or less a step change; I don't see intermediate CPU loads.

Two pipelines that suffer from this problem are:

(1080i video capture and H.264 encode)

gst-launch -e v4l2src input-src=sdi always-copy=false ! 'video/x-raw-yuv, format=(fourcc)NV12, width=1920, height=1088' ! TIVidenc1 engineName
=codecServer codecName=h264enc encodingPreset=3 rateControlPreset=2 bitRate=4000000 contiguousInputFrame=true ! fakesink silent=true

(16-bit/48 kHz stereo audio capture)

gst-launch -e alsasrc ! 'audio/x-raw-int, width=16, rate=48000, channels=2' ! fakesink silent=true

Has anyone seen similar behaviour and been able to diagnose what's going on?

I have used oprofile to determine where the CPU time is going, and so far have been able to conclude that the load due to the codecs and drivers themselves is constant and low, so it appears that it's something to do with GStreamer itself.  However because the GStreamer libraries are supplied in stripped form I can't get much more detail.

Any suggestions or ideas would be appreciated.

Thanks,

Ian

  • 0
    Prodigy 250 points

    Here's another pipeline that behaves similarly:

    gst-launch -e audiotestsrc wave=4 samplesperbuffer=441 is-live=true ! "audio/x-raw-int, width=16, rate=44100, channels=2" ! dmaiperf ! fakesink silent=true

    On successive launches of this pipeline, the measured CPU load can stabilise at about 1%, about 60% or about 85%, to illustrate some values I've seen.  In this case, once the pipeline is running in one of these modes, the CPU load does not vary (at least for as long as I've been bothered to wait - several minutes).

    Just to get rid of the common feature of all the pipelines noted above, I tried replacing the fakesink with filesink location=/dev/null, but got the same results.  So it looks as though this behaviour is not specific to any individual element of the GStreamer pipeline, but to the framework/infrastructure itself.

    Can anyone shed any light on this?

    Does anyone have non-stripped DM36x versions of any/all of the following libraries they can provide so that I can get more detailed information from oprofile?

    Thanks,

    Ian

  • 0 in reply to Ian Willats
    Prodigy 130 points

    Hello Ian, 

    my short recipe to compile gstreamer:

    - install ubuntu 10.04 32bit in a virtual machine or chroot

    - follow the directions in http://tw.myblog.yahoo.com/stevegigijoe/article?mid=366&prev=369&next=363 to set up the dvdsk and the codesourcery arm2009-q1 toolchain

    - make install into ~/install/dm368 (or location of your choice)

    - download gstreamer svn trunk from gstreamer.ti.com - edit "Makefile.common", build with "make all install" in opensource_build, then in gstreamer_ti; "make all" will not work as the prerequisites won't be consecutively put in place as the building process commences

    - copy the resulting libs and executables to the device

    => I had to link "ln -s /target /path/to/build/directory/on/host/target" to make it work (the library reference to glib was hardcoded to the second path)

    You should now have a non-stripped gstreamer in place.

  • 0 in reply to Markus Fritsche
    Prodigy 250 points

    Hello Markus,

    Thank you, your recipe worked nicely and with the non-stripped libraries I am getting more detail out of the profiler as I'd hoped.

    Too early to say what it means, though...

  • 0 in reply to Ian Willats
    Prodigy 250 points

    It turns out that the CPU load figures both dmaiperf and top reported for these pipelines were bogus.

    I believe this is related to the fact that the pipelines are running with natural frequencies of 100 Hz (or sub-multiples thereof).  Forcing the audio pipelines to run at natural frequencies that are not synchronised with 100 Hz -- for example, by changing samplesperbuffer in the case of audiotestsrc -- results in stable (and more believable) CPU load figures.  Having written a simple performance monitor based on counting idle time, this reports stable and sensible CPU loads for all the pipelines.