Feature Proposal

Redesign pre_capture to throttle load when many frames have to be processed

Feature proposal added by JoergWeber - 15 Sep 2004

---

Proposal 100% supported. This is very much needed.

I have started this topic to discuss how to implement it.

I have been thinking. A simple way would be to let Motion process TWO frames for each pass.

Let us assume that the pre_capture is set to 10. We assume the buffer is full.

• We detect Motion.
• Motion enter the function motion_detected in motion.c
• Instead of processing all the buffered images it process TWO images setting an appropriate counter - in the cnt structure.
• Next time Motion goes through the loop it saves another picture in the buffer. But again Motion processes TWO pictures.
• After some loops Motion catches up and from now on - as long as Motion is detected - processes one frame. If no motion is detected it stops processing frames.

So Motion needs to track these pointers.

• Position in buffer for next picture frame
• Position in buffer for last frame processed
• Position in buffer for last picture with Motion detected

Would this work?

-- KennethLavrsen - 15 Sep 2004

---

To process two images in one loop sounds good. This way we should not miss frames anymore even with a large number of pre_captured frames.

I see two possible traps:

• We have to make sure to stop capturing at the RIGHT position, when no more motion is detected.
• What happens if no more motion is detected but there are still frames to process in the buffer and then new motion is detected?

-- JoergWeber - 16 Sep 2004

---

This sounds good to me also, but I do have a question. Should there be a strict limit in terms of memory size or number of precapture images? If a user has a camera that streams at 30fps at 320x240 and wants to precapture 10 seconds before motion is detected, that is 300 frames at 320x240. I'm not sure how much memory this would consume, but supposing that a 320x240 frame is 200 kilobytes, then this would be about 58 megabytes. This is a concern to me because I don't think that most users will realize what it takes to precapture images, so they may choose large precapture values.

-- AndrewHamilton - 16 Sep 2004

---

Yes. On the other hand. if a user wants to use Motion to pre_capture a looong sequence and save it when Motion is detected and does not care about what happens after - then why limit toa specific size. Some may fit 4 GB of RAM just for this purpose.

I prefer documenting our way out of it. Motion is used for so many crazy thing that has nothing to do with surveillance so I prefer keeping it as versatile as possible.

-- KennethLavrsen - 11 Oct 2004

---

While watching some nice mpegs taken with the latest mmx-patch, a feature request came back to my mind. Some time ago, there was a discussion about when pre_capture has to be executed and it was clearly said, that this is at the beginning of an event. On the other hand, one (me:-) might want to have very short events in terms of pre_capture but some longer events in terms of the mpeg movies. That would produce even smoother videos while keeping the same amount of files.

The idea was to separate the 'gap' option that triggers an event from the mpeg gap - maybe by adding a new option like 'mpeg_gap'. When doing the pre_capture redesign, please take this into account because I know that at least someone else had the same wish:-)

-- JoergWeber - 02 Jan 2005

---

We agreed on 13 Feb 2005 that the redesigned pre_capture should retrigger when post_capture runs out instead of when gap timer runs out.

-- KennethLavrsen - 13 Feb 2005

---