Feature Request: Blanking frames

Description

This was discussed with sack, Lavr and joergw a couple of weeks ago on #motion so I figured I will add an actual feature request on the wiki

Something like this would really make my day: if %q == 0 and previous %q < framerate: insert blanking frames to video (or just duplicate of the last frame).

This would allow audio recording as it fixes syncing issues and makes viewing videos recorded with occational CPU bursts more pleasant imo. An option to allow this would really make my day.

Roman

-- RomanGaufman - 16 Dec 2007

Follow up

Comments

This sounds like a great way to be able to do sound recording. Are there any drawbacks to adding something like this?

-- BobSaggeth - 27 Jan 2008

---

This is a very good proposal.

Who has the overview of how ffmpeg works to implement it in Motion?

-- KennethLavrsen - 27 Jan 2008

---

I can handle this feature , but at the moment it won't be a high priority , first stabilize current features in 3.2.10 branch for linux/BSD.

Roman , could please post the link to our irc chat about it ?

-- AngelCarpintero - 27 Jan 2008

sure -- http://koala.ilog.fr/twikiirc/bin/irclogger_log/motion?date=2007-12-01,Sat&raw=on

-- RomanGaufman - 29 Jan 2008

---

Created a quick patch for this. There is still one small problem to be solved, it is if we have motion, no motion and then motion again. This normaly results in one movie file, but with the "gap" removed (if the gap time is less than pre_capture + post_capture). It is easiest explained with an example what the problem is. If the first image saved into the movie after the gap is captured just before a new sec, e.g. we just get one image in this sec. That image is going to be streched into one sec.

There is also a problem if you are using minimum_frame_time (fps < 2).

-- DagErlandsson - 18 Feb 2008

---

Found a way to handle the gap problem better, still one situation this can happen. It is when the first frame captured after gap have shot number 0. We can still detect this by also checking timestamp of frame and not only shot number, but it isn't in the patch. I can add it if someone needs it.

-- DagErlandsson - 19 Feb 2008

---

Wow, the patch looks great - will test it over the next few days and come back with feedback. So far patch applied, motion compiled and running

Doesn't this patch fix quite a few known bugs in motion at the moment? -- e.g. the fps detection problems go away, the time based and frame based options now sync up nicely (e.g. post_capture of 25 at framerate 25 will always be 1 second), etc?

-- RomanGaufman - 19 Feb 2008

---

First bug report - with this patch, motion records at 20fps instead of the set 25fps it records at without this patch.

-- RomanGaufman - 19 Feb 2008

---

My bad, it seems I just flat out can't get more than 20fps for some reason with or without the patch. Hmmmmm.

-- RomanGaufman - 20 Feb 2008

---

Here's how I set it up: framerate 30 pre_capture 25 post_capture 1500 gap 1

and I added: cnt->lastrate = 25; cnt->movie_fps = 25;

For some reason motion was recording at 20fps when the framerate was set to 25 - it records at 25fps reliably now that the framerate is set to 30. From there I'm just forcing the framerate of the card and having a post_capture of a minute (that I later cut using on_movie_save) - but that allows me to use post_capture instead of gap to achieve the same thing.

So far, all of this is working like a dream, thank you Dag!

-- RomanGaufman - 20 Feb 2008

---

Awesome jod Dag

I did some test was worked smoothly , let me check also in FreeBSD.

Thanks !

-- AngelCarpintero - 20 Feb 2008

---

Overall it works very well but doesn't seem to work on post_capture frames? - I use post_capture heavily to capture the time between repeat motion for sound recording.

-- RomanGaufman - 21 Feb 2008

---

What is the problem with post_capture? The only "problem" I can see is that post_capture is set to a number of frames, if there is any "missing" frames in one sec the code is going to add them (to the movie). This results, in the movie, a somewhat longer post capture time than post_capture*fps. Is this your problem? Or do you see that your sound recording gets out of sync? Where did you set lastrate and movie_fps to 25? I don't recommend to set lastrate as it is used in the code to do a lot of calculations. If you want to force the movie to a specific fps, just set movie_fps to it in event_ffmpeg_newfile. If you set it to lower than the actual fps, it is going to take the first movie_fps in each sec. If you set it to larger, it is going to add the first frame in each sec multiple times.

-- DagErlandsson - 22 Feb 2008

---

I see a couple of things:

1) I have "max_vid_time 600" and in reality I get 601.04 or 599.68 - it doesn't seem to be very accurate.

2) I have "pre_capture 25" and "post_capture 1500" which means I should get exactly 60 seconds of video after the end of motion (I have 25fps forced in the source code) but I occasionally get more like 65 or 70 seconds after the end of motion (most of the time it is 60 seconds but occasionally it's quite significantly off the mark). - I checked the files affected and they seem to be 25fps but towards the end of the motion seem to get a bit of a jerky video (probably due to CPU load).

Unfortunately the videos affected just have tree and bush movements so I can't say for sure if a/v sync is affected - I assume it would be?

-- RomanGaufman - 22 Feb 2008

---

1. max_vid_time can be longer as the time is checked in the main loop, if the time since it messures from the event start (trigger time) and if it more it also saves all buffered images. So the time can be up to max_vid_time + pre_capture + minimum_motion_frames

2. I think the problem here is that post_capture and pre_capture just puts the number of images into the output buffer, when they are taken from the buffer and saved into the movie it checks if it is needed to add frames to keep fps in the movie. What can happen if you have a loaded machine it take more than 60 seconds to capture 1500 images.

There is also an other thing than machine load that can make the capture fps drop. The main loop is not syncronized with time, it tries to guess how long time it have to sleep before it needs to capture an other image. This guess is based on an average of the last ten capture-process times. When we start to have motion we have more to do (save to movie etc.), but we still sleeps based on the ten previous loop times (when we only do pre_capture), so the capture fps drops due to this.

I have attach an other patch v1.1_debug that add some debug texts on the saved images if debuglevel >= 7, e.g. motion -d 7. The added texts is capture time, shot (number within a sec), type of image (pre, post, trigger, motion) and if it is an "fillerframe".

-- DagErlandsson - 22 Feb 2008

---

I just studied the code some more and found that I had missunderstod how it worked. It is NOT the previous ten loop times that is used to calculate sleep time between frames. It is a ten seconds average that is used to finetune it. The main component is the previous looptime. So the framerate shouldn't drop significant when there is more to do (motion detected).

-- DagErlandsson - 24 Feb 2008

---

Hmm, I didn't have access to the box the past 4 days but I do now so I will try your new patch with the debut information and report back.

-- RomanGaufman - 26 Feb 2008

---

Sorry for the late reply - I've been testing this and it does make a huge improvement over not using this patch but it seems I can't quite time the audio recording start when pre_capture is 2 seconds and I do a sleep 2 before arecord it seems the audio is off by a second or so.

Without pre_capture it seems quite good.

-- RomanGaufman - 30 Mar 2008

---

I've been experimenting further with this and I've created a 2 second empty wav file that I append to the beginning of my sound recording to compensate for pre_capture 50. Doing this has so far given me great a/v sync! -- This patch rules and I really hope it makes it into motion 3.2.10.

-- BobSaggeth - 06 Apr 2008

---

Applied to svn trunk ( svn -r328 )

-- AngelCarpintero - 13 Apr 2008