Video Smoothing From Event Start To Stop

Description of Patch

This proposed patch implements three main features:

1) Microsecond resolution on images (not changing the way motion currently handles image timing; just tagging for reference),

• a) Accessible as a standard conversion specifier as %us (for the microsecond part of the second).

2) Video smoothing (much like the previous framerate filler patch),

• a) Implemented using microsecond resolution. Priority is given to motion frames, but ALL images moved to the ring buffer are subject to potential usage.
• b) The time delta between the previously stored image and the current image is taken, and used to determine, based on FPS, whether any "filler" frames are necessary. If it is necessary to insert 1 or more filler frames, due to previous high CPU consumption, lag in capture of video from the camera, etc., the PREVIOUS image is repeated to catch up to the current image's time, then the current image is sent to the output buffer.

3) Image capture from precap + event_start to event_end (for video only).

Enable this by setting "smooth_video" in thread conf file.

Because images are constantly evaluated for output to the buffer, there is no lag in processing or video given the following scenario:

• Motion occurs at T=0, and continues to happen regularly until T=10. No motion is detected from T=11, until T=30. Given a gap of 30 and an FPS setting of 15, that would mean without continuous encoding, 300 frames would need to be encoded prior to current and future frames being processed. This creates a CPU usage spike, and causes delay in the video.

Patch workings

... more to come.

Installation of Patch

Download the patch file containing the name "smooth video". 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.

Thanks to sack for repackaging the patch!

Change History of Patch

• 1.0 Initial revision

Discussion and Comments

---

r2 of patch (13 Jul 2008 - 19:39) has a monstrous memory leak which brings down my DVR within minutes - avoid this revision!

r1 seems to work well, videos look a lot more pleasant.

-- RomanGaufman - 14 Jul 2008

---

CPU utilization tripled with this latest patch - Where before motion was taking between 10 and 20% cpu, it now takes 40-50% - avoid revision 3 (15 Jul 2008 - 04:45)

Oprofile is pointing to:

1103895 19.4656 motion motion dilate9
906619 15.9869 motion motion dilate5
432109 7.6196 motion motion erode9
387376 6.8308 motion motion erode5
375848 6.6275 motion motion alg_labeling

-- RomanGaufman - 15 Jul 2008

---

Uploaded fixed version of patch on Bill's behalf (15 Jul 2008 - 12:45), this one is working and doesn't appear to be leaking memory or causing any dramatic CPU utilization increase.

-- RomanGaufman - 15 Jul 2008

---

Latest version uploaded with extpipe against trunk 382

-- RomanGaufman - 16 Jul 2008

---

Latest patch ready to test against svn trunk. Thanks Bill

-- AngelCarpintero - 25 Oct 2008

---

We still mix up 2 different things with this patch:

- add filler frames to have the correct number of frames per second (agree with this one).

- continuous capture during an event even after post capture.

The first one is a really useful one, especially with higher framerates and on busy machines. We still have to offer the option to turn it off. The second one really changes motion behaviour. This 'gapless' feature has to be removed from the patch. The user can run this mode when 'gap' is set to '0'. No need to change behaviour again with this patch.

-- JoergWeber - 03 Nov 2008

---

Have been using this since July 2008 - one of my favourite patches I use with all motion installations - please add this to trunk.

-- RomanGaufman - 18 Mar 2009

---

Roman, if you want to get this patch implemented, we must talk about it - as I said earlier. What is the current version exactly supposed to do? Microseconds? Don't see the need for that. Changing behaviour of 'gap'? Why? 'gap 0' is working wwell now.

The only need that I see is keeping the framerate calculation accurate at the time a video is started - actually all the time, but at the start is is really important. And of course the filler frames, but we still want to keep it an option.

Let me know what you think about it.

-- JoergWeber - 06 May 2009

---

1) I didn't write the patch so I'm not sure, but the result is much smoother videos.

As I understand it, instead of spiking the CPU at the end of every second with duplicate frames (filler frames), whatever frames are available are split across the entire second. So you get far smoother movement.

With filler frames you see the start of a movement, then pause with say 5 filler frames, then a jump to the next second, more frames for the next second, it looks extremely jerky..

The videos are just night and day difference with this patch.

2) Not sure what microseconds are for - I believe it's an aesthetic change mostly, to be able to use in the video instead of the frame number for example.

3) Yes, changing the behaviour of gap because post_capture is frame based, gap is time based. It's hugely inaccurate to specify post_capture 3000 because that could be anything from 2 minutes and 20 minutes with IP cameras (as they reduce framerate based on the amount of available light) - presently gap is the only way to specify the amount of time motion should record after the end of motion.

Maybe instead of altering the behaviour of gap, add pre_capture_type time that will change pre_capture and post_capture options to use time instead of frames?

-- RomanGaufman - 20 May 2009

---

Come on, commit this already

-- RomanGaufman - 26 Aug 2009

---

Anyone?

-- RomanGaufman - 21 Jan 2012

---

• smooth_r443_r5.patch: Credit to Darkwind

• motionx_r468.patch: Patch against r468