Remove 'low_cpu' Feature

Description of Patch

Since the introduction of the 'pre_capture' feature, 'low_cpu' doesn't work very well anymore. The pre_capture buffer is even used for some other features like 'minimum_motion_frames'. Motion is not consuming much CPU resources when idle, so it has been decided (Kenneth, Angel, Joerg) to entirely remove the 'low_cpu' feature. Below attached patch will achieve this goal.

Installation of Patch

Download the patch file. If it is packed as a gz or tar.gz unpack it first. Then copy it to the motion source directory and issue the command (assuming the patch file is called filename_of_patch_file.diff)

patch < filename_of_patch_file.diff

Then re-build Motion and test the patch.

Change History of Patch

• 1.0 Initial revision

Discussion and Comments

---

We need to consider one thing.

The low_cpu framerate was used as a terrible hack and work around to get the framerate right in the ffmpeg generated films.

Now that pre_capture is handled better - do we still have a potential problem with the calculation of actual frame rate in the ffmpeg mpegs?

The reason we had the problem was that the used framerate was based on a calculation on the time from last frame to current - and this became too long because Motion loads the CPU much more when Motion is detected and that can lower the actual framerate to a value lower than set with framerate.

Especially the old pre_capture caused this issue. But maybe this is better now.

In any case the old hack was terrible and not a good reason to keep low_cpu. If we still have a problem - a better way to set the framerate is the right way to go.

-- KennethLavrsen - 19 Aug 2007

---

I'll review the code again to see how this is related. Thanks for this important hint!

-- JoergWeber - 19 Aug 2007

---

The ffmpeg fps is calculated in event.c - event_ffmpeg_newfile like that: If low_cpu is set, we pass the framerate from the config file to ffmpeg. Otherwise we use the calculated framerate cnt->lastrate, which is calculated in motion.c. Everytime we start a new second, cnt->shots + 1 (that was an off by one bug some time ago) is copied into cnt->lastrate. I don't see an issue by removing the low_cpu feature. Anyway, I will wait until Dags new patch is comitted, because it is easier to adapt my patch to match his codebase than the other way round. Do you (all ) agree?

-- JoergWeber - 29 Aug 2007

---

I have committed the removal of the low_cpu feature into SVN today (r219).

-- JoergWeber - 03 Sep 2007

---

I'm thinking that the new pre_capture isn't implemented properly in the SVN branch... I am getting preliminary delays and dropped frames at the point of motion detection that I wasn't getting in the branch of the code where the enhanced pre_capture was being developed.

-- JeffGroves - 09 Dec 2007

---