Please Publish Hardware Hardware Requirements for Smooth Video

Question

I have gone from a 500MHz machine to 1.7GHz and still get dropped frames, even when using a low frame rate of 10fps. Could you publish some information as to what hardware is required (CPU, drive speed, etc) to get smooth video of 15 to 30fps?

I am currently using a P4 1.7GHz, 512M RAM, IDE Drive, cheap generic 4-input bt848 card. I am recording 1 channel of 512x384 with mpeg4 500kbs, 10fps. The CPU goes to about 75% when encoding.

I don't understand it because this machine (using other software) can record 30fps mpeg4 with no problem.

Perhaps users could post info about their systems and what hardware they are using to get smooth video.

My next step is to go to a 3GHz class machine, but am reluctant to do so so as I've seen no difference between te 500 and 1.7 machines.

Paste in your error messages, config settings, terminal window output etc in this text field.

Environment

Motion version:	3.2.7
ffmpeg version:	SVN-rUNKNOWN
Libraries:	ffmpeg
Server OS:	gentoo 2006.1

-- WaltDoern - 07 Apr 2007

Answer

I wonder what smooth video means in this context.

Motion only records frames to the mpeg when motion is detected unless you tell it to fill up using the post_capture feature AND not using high values for pre_capture.

Can you post your motion.conf? You can attach it to this topic. Remember to remove passwords.

-- KennethLavrsen - 07 Apr 2007

Reply

Hi - thanks for the quick reply. I don't see a "reply" button, so I'm just editing this page. I have attached the motion.conf. Yes, I am using post capture, of 3 seconds (30 frames). Therefore, I will typically get continuous recording when there is movement.

I define smooth video as having at least 15 fps. I would really like to get 30fps as I know that this hardware should have no problem recording at that rate. However, if I set the framerate to 15fps, I get many dropped frames and will typically end-up getting about 10fps. I have therefore set the framerate to 10fps as this is the best that I can do, and I still get the odd dropped frame.

It would be helpful if we could see (from you and other users) what kind of hardware people are using and what kind of performance we should expect. I am thinking of a list of machines and typical framerates that we should expect. For example:

Pentium 500,MHz mpeg4, 640x480, ---> 5 fps

Pentium 1.8GHz, mpeg4, 320x240, ---> 10 fps

If I knew that people are actually getting 30fps, I could try and use the same hardware. If we find that nobody can get more than 10fps with any hardware, I would at least know that it is impossible and I should stop trying. Thanks.

---

Hello Walt,

Here are a couple of things you could try (easiest last!):

It may help you to use the StatisticsDataPatch (you will need to patch Motion and recompile) as this adds another web page to the Motion HTTP Server. You can see the historical frame rate of each camera thread. (Well, over the last 6 seconds anyway). This will let you see if you're getting 15fps one second and 5 the next, from the hardware, which might be contributing to your problems. Perhaps you could compile in that patch and post a screenshot, or just post the data as text. If you have any problems, do say, as I have been working on that patch and am keen to help testers.

The StatisticsDataPatch also shows you a MotionThruPut number, which is the rate at which camera frames are decoded and motion-detected. This is the rate at which frames are stored to the ffmpeg file, and it's slower than the hardware's fps rate. I have only experienced problems related to lack of fps on slow machines (non-PC architectures such as Linksys NSLU2, bogomips = 300). You can find your machine's speed from the bogomips value which is usually found in the dmesg output. (Type 'dmesg | grep bogomips' ).

This thread may be about a similar problem. SupportQuestion2007x01x15x230952 I only use network cameras, so have no experience with capture cards.

I also experienced some strange results (related to quality, not speed) when specifying a bit rate with ffmpeg - like you, I specified ffmpeg_bps 500000. I presume you do not need the precision of 0.5Mbs but are just after high quality images. You could try setting "ffmpeg_variable_bitrate 2" and your current ffmpeg_bps setting will be ignored. This gives ffmpeg more freedom with the bit rate, but preserves highest quality. The bit rate does not skyrocket so you can use the setting '2' without much worry.

I note you are using low_cpu 10 . This might - possibly - be affecting your results. Have you tried with low_cpu 0 and confirmed it is still the same?

-- SimonW - 10 Apr 2007

Reply

Hi. Thanks for the help.

I tried both of these patches:

patch < motion-20051024-051001.diff (as per instructions)

and

patch < SWpatch_StatsThrottle20070323.diff (appears to be latest)

I'm assuming the last one is the latest version. With the first patch, I got a bunch of errors from the patch command (chunk ignored). When a compiled, I got the following error:

---

motion.c: In function 'motion_detected':

motion.c:338: error: 'struct context' has no member named 'total_events'

make: * [motion.o] Error 1

---

I assume that the patch is old. I then rebuilt the dir and tried to apply the second patch and got the following errors during application of the patch:

---

patching file netcam_jpeg.c

can't find file to patch at input line 323

Perhaps you should have used the -p or --strip option?

The text leading up to this was:

|Index: video_common.c

|===================================================================

|--- video_common.c (revision 172)

|+++ video_common.c (working copy)

File to patch:

Skip this patch? [y]

Skipping patch.

1 out of 1 hunk ignored

---

I tried a compile and got the following error:

---

motion.c: In function 'motion_loop':

motion.c:852: error: 'struct context' has no member named 'lost_connection'

make: * [motion.o] Error 1

---

I can see in motion.h that the struct "context" does not have the element "lost_connection". I'm not sure how it ever gets defined?

Aside from that, I can answer the bit about using low_cpu. I have found that if I set low_cpu=0, I will get unusual framerates defined in the header of the avi file. For example, if I set framerate=30, I will really get anywhere from 8 to 12 fps. You would think that the header of the avi file would have something like a value of 30, or maybe 8 or 12. Instead, I find that crazy values are in the header. Most of the time, the header has 15fps, but sometimes it is set to 2 fps (it's totally random). I found that if I set low_cpu=x, it will at least force the value x into the header so that I get something predictable (even if it may not match the actual framerate). So to try an get things to match as best as possible, I selected framerate=10 (which I can usually obtain) and low_cpu=10 (to prevent crazy values in the header).

BTW - I am assuming that the avi file has the frame rate in the header. I check the value with programs such as gspot or virtualdub and find those unusual values like 15 or 2. After using low_cpu=10, I have found that it is always=10 in the avi file.

As for the bitrate, I've tried using the variable bitrate and have found that it made no difference in dropped frames. BTW, even though I set the bitrate to 500k, when I check the avi file with gspot for virtualdub, they report the bitrates anywhere between 250 and 900. I therefore don't know if this bitrate setting does anything. I might as well use the variable bitrate as you suggested.

---

Thanks for trying my patch. We will look at why it didn't work in just a moment. First, your other points:

I also found that the bitrate was not reliably controlled when I used ffmpeg_bps 500000 ... it varied in the same way you describe. I was using mpeg-1 and an mpeg bit rate viewer to check out the files. Interesting that it works wrongly with 2 different codecs!

Now your frame rate comments. I agree. As far as I can read in the source, the method of setting the frame rate for an ffmpeg film is like this: it uses the number of frames obtained from the camera in the last second, unless that figure is less than 2 (it then uses 2) or over 30 (it then uses 30). With low_cpu in effect, I don't remember what it does, but it seems to work more as expected for you. Perhaps someone needs to spend some time looking at the whole fps-of-a-movie-file area.

It would really help you to know your frame rate is constant or variable, since the frame rate is used in the header of the avi as we have seen. So on to why the StatisticsDataPatch didn't seem to work....

Now, my latest patch "SWpatch_StatsThrottle20070323" is really for use with the SVN version 172, which is a couple of digits behind the current SVN but should still work. The latest SVN's have Video4Linux2 built in and many other improvements.

I would not expect my latest patch to work with motion 3.2.7 since there have been many changes since then. In fact video_common.c is a whole new file, which of course is why the patch fails to patch it in 3.2.7. If you would rather stick with 3.7.2 for other reasons, you could temporarily use the latest SVN version to access the Statistics data (install and compile in a second directory ; do not 'make install' but run it from the directory), then when you know the answers, then return to using your 3.2.7.

Btw, lost_connection is a variable found in motion.h in the latest SVN - but does not appear in version 3.2.7. That must be why 'patch' failed to make the change. Again, a reason to begin using the SVN version. Alternatively, a daily snapshot could well be the best route if you do not wish to install an SVN client... the 11/04 daily snapshot contains the lost_connection variable.

I don't know your style of source code management, or if you're just experimenting with motion. You might find it best to keep a work-in-progress motion directory separate from a known-good set of motion source files - if you are keen to keep a working version available at all times. (I do this since my installation is running motion 24/7). Then you may not mind that your motion source files don't compile to a working object for a few days while you debug.

-- SimonW - 11 Apr 2007

Reply

Thanks. For my working copy, I'm using a Gentoo "emerge" package. Anything else, I just compile and don't install.

Without the stats pack, I can look at the info on each frame which shows the frame number, and the time. During each second, I'll get roughly 10 frames (it is fairly consistent for each second).

However, I'm straying a bit from my original query. So far, I've never heard if anybody has ever achieved smooth (30 fps) video with any hardware. I must assume that it is not possible. For now, I'll have to use (dare I say it) the Windoze app that came with the card (don't laugh, it works).

As for why this particular app has such low frame rates, I can only guess. Other linux apps that only record have no problem. I suspect that the only difference is that the motion detection portion is taking all the horsepower. Just throwing out ideas, but I would think that once motion is detected, there should be a thread that devotes the bulk of the horsepower to encoding/recording video. A separate (lower priority) thread should then check if motion has stopped. There would be no consequence if this lower priority thread "took it's time" looking at the frames. The result would be that you have a couple of extra seconds of video tacked onto your film (which is what people do with post_capture anyway). After video recording has stopped, then the bulk of the horsepower can go back to the thread that is watching for motion.

---

Yes we have strayed a bit.

I have done a bit of looking around at what happens when motion is detected, related to another patch, and I found that there is a global flag - yes, global - which says when motion is being detected or not. That flag affects the frame rate of all threads using low_cpu. So when motion is detected, they all begin sampling at higher frame rates - even if only one thread has motion in it. I don't know if this is intended behaviour or not, and will ask a question elsewhere. (It might cause variations in the movie frame rate of threads with no movement ocurring).

>> As for why this particular app has such low frame rates, I can only guess. Perhaps Kenneth knows something about that. V4L library/drivers for example. You could try setting output_all to 'on' and a sky-high framerate, and see what you then get in the ffmpeg movie. You're not using Round Robin are you? I use only netcams, and I know that netcams use a Jpeg-decompress routine which is mutually exclusive. That limits the frame rate which can be motion-detected (and thus recorded in a movie). For conventional cameras, I do not know if they have the same issue.

The StatisticsDataPatch (if you can get it working) would tell you the MotionThruPut, which is the maximum rate that could be recorded into a film. If that, say, is 10fps, then it is not possible to record 30fps video while performing motion detection.

There is some logic in the source code which detects motion using a fast or slower method. It goes like this:

• Normally the fast motion detection algorithm is used (alg_diff_fast) which looks at at every other pixel. This routine does not handle masks, or night compensation (only the slower algorithm does that).
• If motion is detected using the fast algorithm, motion then appliesthe slower one to find out exactly how much motion there is. Or discount it if it falls under a mask, etc.
• If motion has been detected (in any thread, see note above) then for each subsequent frame until post_capture expires, in order to see if there's still motion we don't bother trying the fast one first and just use the standard algorithm.

It does seem strange that the CPU power required increases once a motion is detected. And perhaps an oversight that motion detected in any thread will cause side-effects in others. Perhaps it has remained since motion was converted from a single-camera application to multi-camera.

For my application with my slow server, I thought of altering this logic but have not done so yet. It would have to be under control of a config file option, to set a 'fast motion detection only' mode. Possible changes would be to use the 'fast' algorithm at all times (obviously the limitations of that would be clear, no masks and no nightcompensation). This should free up some CPU horsepower during motion events which might get more frames per second into the film (unless something else is a bottleneck too).

I could do some patches (in a medium time-frame) to experiment with some of these things if you would like to test them.

-- SimonW - 12 Apr 2007