Excessive CPU use while capturing

Part of the trouble is with jpegenc in PhotoSaveBin. If i understand it right, it is encoding all the time. If i replace jpegenc with identity the utilization is reduced (the capture is broken, obviously, just looking for cpu hogs). Even with this, the cpu gets hit, but at the same level than cheese (about 50%). With jpegenc enabled y see two proceses with 50% each.

Perhaps it could be possible to link jpegenc right before the snapshot is taken, and unlink it after.

Thanks for the test/hint around jpegenc. Perhaps also i can reduce with a filter the encoding framerate with jpegenc.

In thosedays , I have some internet access troubles. So when I stabilized back on line, i will take time to read/analyze the problems

Just to leave the results of a bit more testing.

In first place, it seems framerate dependant: i tried a slightly newer logitech (046d:0991), and it worked at a much higher resolution (1600x1200), with a much lower cpu utilization (around 25%). The framerate was pretty low, tough.

Now back to my webcam:
If i remove the overhead from jpegenc, the cpu consumption goes to 50-60% (in a core 2 duo machine, sigh ). The only way to further reduce seems to be to use a lower frame rate right from the camera.
For example:

# gst-launch-0.10 v4l2src ! ffmpegcolorspace ! ximagesink

uses 70% cpu, while

# gst-launch-0.10 v4l2src ! video/x-raw-yuv,framerate=5/1 ! ffmpegcolorspace ! ximagesink

uses under 15%. (5 FPS is the lowest framerate my camera will negotiate).

Of course, this would reduce the framerate in the preview window also...

So, it seems that beyond the jpegenc issue, it's all about gstreamer performance. The only way to optimize beyond that is to look into the pipeline configuration carefully.

Hi,
interesting tests . But it seems hard to understand why it is linked to webcam models, and futhemore how to tune gsteramer for that.

I have ineternet connection back, but i m off until 21th of january. When I m back I will make some tests on that problem.

Ok, I have the same kind of performance results by reducing the framerate.
I don't know if writing the pipelines in C instead of python can reduce the CPU load ...

So performance seems webcam , and framerate dependant. It can be also USB bandwith dependant.

I don't think python is part of the problem, as it only is used to setup the pipeline. All the processing while the pipeline is running is done inside gstreamer libs (unless there's some per-frame callback to python code).
In my case, the load was mostly framerate dependant. Different webcams try to run at maximum possible resolution, and then set the maximum rate for that resolution (to fit in the USB bandwidth). So, a newer camera at a higher resolution used actually less cpu, because it ran at a lower framerate. So a simple "solution" would be to reduce the framerate at the input (5-10fps?).

Either way, the jpegenc use should be optimized out.

Yes I agree to reduce the webcam's framerate.
I try ti detect the framerate from the plugged webcam. To know the correct Max and min range. And parhaps and in the options menu the possibilty to increase/decrease the framerate for CPU load process.

Than to take also a closer look of jpegenc, and optimize also the mixer feature.

Hi,
A pre version of luciole with variable framerate is available on launchpad. The dedicated branch is here : https://code.launchpad.net/~nico-inattendu/luciole/bug_excessive_cpu

Now luciole during webcam detection, scan for available framerates.
On project properties window, a scale bar is available, to modify the webcam framerate.

I also add a pop up to request user to update the project with webcam detection, when an 'old' luciole project is loaded

I think this version is redy for test. I go to make some code reading and deeper tests.

Tested it, at minimum fps (5 in y case), goes about 18-20% CPU. Now my laptop isn't burning my hand (the CPU fan blows to the right, where the mouse is), as if it was going to melt. Cool :)

Thanks for the test

I right now pushed a new revision to try to optimise jpegenc : I fixed an input framerate of 5 fps.

For mixer also : the image to mix framerate , i.e the image mixed with webcam acuqisition, is fixed at 1fps instead of 25 fps.

May be it can fix bug #500652 . The goal of mixer is to mix the last image taken with the current acqusition. Help to decompose an object move.

Perhaps the fps bar could be also placed in the initial project setup window? I'm not sure it's a good idea, it could be confusing. Or perhaps default to the lowest fps (with a minimum of about 3-5?).
(i'll look at the mixer and comment in the other report)

This bug was fixed in the package luciole - 0.8.2-0ubuntu1

---------------
luciole (0.8.2-0ubuntu1) lucid; urgency=low

  * New upstream release. Fixes:
    - LP: #498619 Acquisition doesn't work on DVCAM nor WEBCAM
    - LP: #500649 Excessive CPU use while capturing
    - LP: #500158 Impossible to change export path
    - LP: #500652 Weird Mixer behavior
    - LP: #505288 Error when opening existing project
  * Switch to dpkg-source 3.0 (quilt) format
  * debian/README.source: deleted as it's not useful anymore
  * debian/quilt: deleted build dependency on quilt
  * debian/compat: bumped version to 7
  * debian/rules: Converted to debhelper 7 style
  * debian/manpages: created to install luciole.1 manpage
 -- Fabrice Coutadeur <email address hidden> Mon, 08 Feb 2010 20:09:50 +0100