One Large FFMpeg file with Event Numbers updating

Description of Patch

(Topic pruned to improve readability, 19 Mar 2007)

I previously asked a question about 'getting all motion in one file' without using gap=0. I intend to make one file a day, and need the event numbers to update - to help my back-end processing - which with gap=0 they do not. I couldn't get acceptable results with standard Motion config option settings but I was new, so thought I just hadn't discovered how to do it yet.

I discovered that msmpeg4 was a bad choice of codec for a file of 'all movement in one day' since it cannot be viewed before it's closed. And we all like to look at what's been going on before a whole day is complete! Mpeg-1, although not the most modern codec, is a better choice as it can be viewed even if something like a power fail (happened to me today) shuts down the machine.

My first patch (now removed from here) used a modification of the ffmpeg_timelapse parameter. This however was high on KennethsNerdoMeter. It only sufficed to prove the concept.

I originally also had a problem with mpeg-1 film quality degrading over time. This was when I specified a bitrate and not a quality setting. For the detail, see FFMpegIncreaseFilmQualityPatch. But in summary, don't specify the bitrate, only specify the best quality like this: ffmpeg_variable_bitrate 2

Background:

I'm using motion with 2 netcams recording jpeg files on movement on the street outside - it's all working well. I'm running at 2 fps since I'm using a lightweight server (Nslu2 with Openslug).

-- SimonW - 23 Nov 2006 (edit 19 March 2007)

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

• Initial version - incomplete solution
• 5 First released version which allows ffmpeg_cap_new hourly/daily/etc
• 6 Improved version.
• 7 Latest version for testing. Working well for me, in use 24/7.

Discussion and Comments

---

Thank you very much for your contribution.

(snip by SW 19 Mar 2007)

You are not the only one that requested a one long mpeg. Using gap=0 is a workaround with negative implications. And as you say mpeg4 and msmpeg4 files need to be closed to view them.

ffmpeg 0.4.8 could cope with mpeg1 in non 25/30 fps but that was changed in 0.4.9 and all the CVS and later SVN versions later. (ffmpeg stopped making releases after 0.4.9 )

Thanks again for your contribution. If you want to help us with later integrating the patch then consider developing it in an SVN checkout. Then you can make patches very easily. See MotionSubversion for more information how to.

-- KennethLavrsen - 24 Nov 2006

---

Thanks Kenneth, I am happy to keep developing the patch until it is suitable for incorporation into the main code -- it gives me what I need for my security application 'right now'.

Firstly, for me the jerky movement of people (or objects) once motion is detected is expected, since I am running with a slow framerate of 2 fps. I don't increase framerate once motion is detected, as the machine does not have the power. So, jerky video is to be expected from this. All frames are timestamped so that's enough.

The 25fps of an ffmpeg movie is not a problem. It's cool to watch a day's events compressed into 5 minutes of real-time .... clouds passing over, etc. And I can step frame-by-frame to review any events of interest. I use VirtualDub on a Windows machine to review mpeg files if I need to.

-- SimonW - 24 Nov 2006 (edit 19 March 2007)

---

OK we have a big step forward. I have pruned the previous entries in this thread to remove some 'ramble' which will especially help new readers.

I have attached the patch 'SWpatch_MovieRollover4' which permits Motion to roll over its ffmpeg movie files (the one containing captured frames of events) at various intervals. This gives me exactly what I wanted for my security application - one movie file per day, containing all the motion events. I use the Motion event number on the on-screen titles to allow me to identify what frames belong to what event.

In the patch, config option ffmpeg_cap_new has been given some new choices as follows:

# Use ffmpeg to encode mpeg movies in realtime (default: off)
# Set to 'on' for a new movie file for each event, or set
# to 'daily' for a single movie file containing all events.
# Also: 'hourly' 'weekly-sunday' 'weekly-monday' 'monthly'.
# Conversion Specifiers can change the filename on the hour etc.

ffmpeg_cap_new hourly

Eagle-eyed motion users will recognise the same choices as for timelapse videos.

The 'rule' for rollover of a video file is that if an event is in progress, and it is time to roll over the files, the current file is closed once the 'gap' period has passed. This means that an event will not span across 2 or more files - which seems to be best.

It should be fairly obvious to most Motion users that the name of the video file should be unique - if it is rolled over every hour, there should be part of the file name which differs based on the hour! If daily, include the date in the file name. Confusing problems can arise if this is not done, since Motion will silently write over files that already exist.

The ffmpeg_codec must be set to mpeg1 - if it is not, a message is printed in the log, and the codec is re-set to mpeg1. Until other codecs are identified that produce viewable files if the machine experiences a power failure (no warning to close files) then I think it should stay that way.

(There is a second new config option, ffmpeg_fps. This has been added to permit experiment with older ffmpeg versions - if you have one. If set, it over-rides Motion's method of defining ffmpeg fps, which is the actual fps used in the last second of motion capture. Unless you know what you are doing, you should not set this option. Incorrectly set it may cause Motion to terminate with an error from the ffmpeg library. For details refer to the conf.c file, or make Motion re-write a new config file to see the option explained).

I have been testing this patch for quite some time now, and have fixed any problems I saw. It works very well for me, and it would be good if others could test it also. In my system I only have netcams, which run at 2fps. Other users (V4L/V4L2, high framerate, etc) would be interesting to hear back from.

-- SimonW - 19 Mar 2007

---

Just noticed that the patch posted contains some references to ffmpeg_cap_new = 'one'. They are in comments and motion_log output, so do not affect the basic function.

This was from an earlier stage of development, it is now possible to use hourly/daily/monthly etc. 'one' is not a valid setting. I will correct the comments etc at the next revision, when there may be other bugfixes etc.

-- SimonW - 20 Mar 2007

---

Patch named SWpatch_MovieRollover7 attached, with incorrect comments fixed. Also the patch is larger as previous one had all changes to event.c missed out! It's correct now.

I would be interested to hear others' experiences of this patch. It solves one of the larger missing features of Motion (ie. that all movement could not be put into one file per hour/day/month. Now it can. And the event numbers work fine. The workaround of gap=0 was an inadequate solution since events did not increase, this does not need to be used anymore).

-- SimonW - 29 Mar 2007

---

I have attached a more up to date patch, based on SVN 223. No new functionality, just compatibility.

-- SimonW - 09 Oct 2007

Again, adjusted the patch for SVN 292 compatibility. Should also be good for Motion 3.2.10.

-- SimonW - 14 Jan 2008

---