Using playbin2 causes high CPU load on embedded system

[Edward Hervey]

Hi,

On Fri, 2011-10-14 at 08:56 +0530, Icarus Alive wrote:
> On Wed, Oct 12, 2011 at 1:03 PM, Edward Hervey <bilboed at gmail.com> wrote:
> >  Could you profile *where* the extra cpu usage is being consumed ? This
> > much overhead (2 times) is unusual.
> 
> Thinking again (harder this time), those nos. were for a test I did
> over 4-5 months back, and there is a chance of misreporting the exact
> difference, as there were quite a few tests we did. However, the diff
> was still significant (at least 10-20%).

  It's getting a bit more acceptable though (reasons below). I'd expect
the overhead of using playbin2 over hardcoded pipelines to be in the low
single-digit percent overhead. That overhead would be due to having a
bit more elements/pads involved, but which should all be configured to
pass-through data when transformation/processing isn't required.

> 
> >  You can use "valgrind --tool=callgrind" for example (with
> > synchronization disabled on the sinks so as to not have the pipeline
> > have QoS kick in).
> 
> Not sure how to disable sync on the sinks. Is it one of the properties ?

  Yes, all sinks have a 'sync' property that you can set to False. With
playbin2 you can specify what audio/video sink you want along with
properties (pay attention to the quotes if setting properties on those).

  Ex : playbin2 uri=file://... audio-sink=fakesink
video-sink="xvimagesink sync=False"

> 
> >  Also, what audio/video sinks are being selected by playbin2 ? (you can
> > see it with gst-launch-0.10 -v playbin2 ....).
> >
> >  What does your 'non-playbin' pipeline look like ?
> 
> Will share the graph when I have access to the test-bed again.
> 
> >  Finally ... the VM might also be introducing some side effects
> 
> This is indeed what I'd suspected. Had tried to minimise use of host
> machine, and apart from possibly a notepad being open and background
> services, the VM was pretty much all that was running.

  My experience has generally been that developing in VMs is fine ...
until you start using synchronization and audio/video outputs.
  There's too many unknown kicking in (you're no longer doing 'pure' cpu
processing which is executed without any overhead, but using the VM's
guest 'devices' which translate/forward data and instructions between
your guest and host).
  The situation might have improved since... 

> 
> > On Wed, 2011-10-12 at 00:41 +0530, Icarus Alive wrote:
> >> On Tue, Oct 11, 2011 at 6:56 PM, M. Amirul Syahmi
> >> <amirulsyahmi at gmail.com> wrote:
> >> > Try to play it using Hardware accleration
> >>
> >> That might help, assuming your system has HW-acceleration. Also, I've
> >> found that some non-gst based apps (e.g. vlc) plays a media
> >> file/stream lot more smoothly than a gst pipeline, without
> >> HW-acceleration. Tested in a Virtualbox setup with HW acceleration
> >> disabled in guestOS.
> >>
> >> > On Tue, Oct 11, 2011 at 9:17 PM, stuart68 <stuart68 at gmail.com> wrote:
> >> >>
> >> >> Hi
> >> >>
> >> >> I added the following flags to help, but it was still not enough:
> >> >>
> >> >>        g_object_set(G_OBJECT(playBin),
> >> >>                        "buffer-size", 150000,
> >> >>                        "flags", 0x02,
> >> >>                        NULL);
> >> >>
> >> >> This helps to reduce the memory being used, but there is nothing I have
> >> >> found that helps to reduce CPU load.
> >> >>
> >> _______________________________________________
> >> gstreamer-devel mailing list
> >> gstreamer-devel at lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> >
> >
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> >
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel