BUG: gap setting does not include 'post_capture' frames
In the documentation for the gap setting, it indicates that the timer for gap is supposed to start after the post_capture has finished its last frame, but this doesn't seem to be the case. If I set gap to something lower than post_capture, motion ignores the post_capture frames and opens new mpegs at the rate dictated by gap.
Test case
If I have post_capture set to 1000 frames and set gap to 10 seconds, then the gap timer should start as soon as all 1000 frames have been processed, but it doesn't, it just captures 10 second mpegs.
In my case, I wanted motion to start a new incident number as soon as post_capture was done, so I set gap to 0. I came home to find several thousand < 1 second mpegs waiting for me.
Environment
Motion version: |
3.1.17 |
ffmpeg version: |
0.4.8 |
Shared libraries: |
ffmpeg |
Server OS: |
Debian custom 2.6.10 |
--
TerryRiggins - 30 Jan 2005
Follow up
I will look into this one. This is a bug. It has not been fixed in 3.1.18 I am sure.
I have looked a little at the code. It should in principle work. And I think it does if gap is larger than 2. It is the very small number that seem to cause the trouble.
I tried with framerate = 2, post_capture = 10, gap = 0 and I saw the same as you.
Then I tried setting gap to 1 and still same problem. But at 2 it seems to work. It may have something to do with the order in which the different decisions are taken (new event is triggered before post_capture in the loop).
--
KennethLavrsen - 30 Jan 2005
Fix record
Fixed in 3.2.1_snap10 and 3.1.20_snap3.
The error was fixed by moving the block of code handling make movie and gap down after the motion_detected function has been called so that time variables belong to same frame.
Additionally I added the feature gap=0 which now also works. It disables gap completely so that one single mpeg file is created. You can end the event from the remote control interface using for example cron. This makes Motion close the mpeg and make a new with event number increased by one.
--
KennethLavrsen - 27 Mar 2005