ZoneMinder Forums

Hi,
I bought 2 vivotek fd7160 cameras. So far they are great, mjpeg is clean, with all the headers and bits and they are performing nicely. They are capable of 1600x1200 mjpeg stream at 15fps.

However my dual core AMD 4400+ server with 2GB RAM can't keep up. I thought this wouldn't be a problem, but I have just one camera connected now at 1600x1200 as "modect" and it's streaming 8fps live but only recording 3.7fps for the events. So far it seems the processor is the bottleneck

Network is 1gbit, between the camera and the server, there is a 1gbit switch. The network is not a problem, camera needs 10mbit at most to stream conveniently.

When I set the camera as monitor, the CPU usage drops noticeably, but the camera is useless to me then
When I set it as record the CPU usage drops slightly, but not that dramatically as I would expect (zma 40% CPU, zmc 30% CPU)
Modect is crazy (zma 70% CPU, zmc 30% CPU).

What is the problem? I know that decompressing a JPEG that big is a lot of work, but still, this is a pretty good CPU.

Any tips? I can live with one of the cameras working at 800x600 but one of them must be 1600x1200 because I want to be able to zoom it. Can I somehow use the motion detection the cameras offer? The cameras can do RTSP with MPEG, would that be noticeably faster (I can't get it to work as of now, but I know it's doable, I am using it with another Vivotek camera). What about the motion detection only checking half of the frames, skipping one frame in between?

I am using Debian Sid, amd64 so MMX, SSE2 and other optimizations should be turned on for libjpeg62 and other libs. I can't think of anything else.

Thanks a lot, I am a newbie in this area but I know Linux and C so if needed, I can hack a thing or two.

Did you...

http://www.zoneminder.com/forums/viewtopic.php?p=46203

Interesting post, please let know.

Regards.

J.

So your main issue is the Motion Detection, the good news is there is a lot you can do here to help! To start as you said, set the max fps to something low (say 4 fps) and the alarm FPS to what you want to record at (say 15 FPS). This will help keep the load down when not in alarm mode. The second, and most important thing you can do it minimize the alarm zone work the system must do.

Make the alarm zones as small as possible (and if you don't need a more advanced detection mode use a faster one). This is a biggy, many people leave their alarm zone as a big rectangle over the entire camera, when really they may only need to have a zone over a door in the picture or what have you.

While not a 1:1 ratio, you get a very nice return by minimizing the size of a zone. So if your zone only really needs to be 25% the size it was, you may see say a 60-70% reduction in your load.

Also obviously try the optomized jpeg libs as they certainly are helpful:)

whatboy: 32bit only, I am on amd64
mitch: will try that when I get home, won't it just postpone the bottleneck until 2 alarms kick off at once?

Reducing the FPS yes, reducing the zone size no.

You can set you zones to 'Alarmpixels' or 'Filterpixels' to reduce the complexity of the motion detection algorithm.

You can try enabling the 'FAST_IMAGE_BLENDS' option and disable the 'CREATE_ANALYSIS_IMAGES' ( both found under the 'Config' tab).

timcraig: done and done. I was already using the fast method of motion detection so it didn't really help though

OK, so the load is down from 1.2 to 0.9-1.0 for just one camera@4fps,15fps when in alarm state.

This still sucks I would ideally want 8fps@idle and 15fps alarm state for both cameras@1600x1200.

Do you think a SIMD version of libjpeg for amd64 would help?

Each processor has its own optimization libs (intel IPP vs AMD's) I haven't worked with AMD's but seen very nice results from Intels so you may see similar if you don't care about getting your hands a bit dirty.

I think the main problem is the way Zoneminder saves events. It saves them as series of small jpegs instead of employing something like one mjpeg for one event.

ZoneMinder has to decode jpeg, analyse it, encode it again and save it. The filesystem would definitely work better if it had to read/write one big file instead of hundreds of small ones.

However I have heard that Intel and AMD have some optimization frameworks that are API compatible, so it may be possible to hack a special libjpeg that would use these libraries, I will look into it Intel's library is the IPP, AMD's is something like "Framework"? I dunno.

also in the camera settings ther is an option skip frame witch will make zoneminder skip frames for motion detect so on a 8 fps cam set it to 7 so it does motion at 1 frame every second rather that 8 times per sec

However I have heard that Intel and AMD have some optimization frameworks that are API compatible, so it may be possible to hack a special libjpeg that would use these libraries, I will look into it Smile Intel's library is the IPP, AMD's is something like "Framework"? I dunno.

Did you...

http://www.zoneminder.com/forums/viewtopic.php?p=46203

see the above forum link thats what it does

The way ZM stores and processes video is just about the best way to do it. It decodes any format to a common medium for analysis, then writes it out as a jpeg (not overly intensive). This could cause issues if your IO bound but in that case add another drive and raid them. Storing as JPEG's allows the web interface and external programs access to the content easier than the awkward mjpeg format. There is very little CPU that would be saved by changing it (which is what this topic is about I would assume). Intel IPP would almost definitely speed things up (as I mentioned previously) and it comes with a slew of examples showing JPEG encoding/decoding so by all means if you have some ability to code go for it.

kingofkya: Thanks for the Frame Skip tip! The MMX libjpeg is 32bit only as I said above.

mitch: yeah, I guess it would, I plan to fiddle around it when I have some time.

What filesystem are you using? That also cause an impact on the performance of the system.

depeding on what elts you system is doing but the modefied libjpeg gives far more gains that a 64bit os

example i could run 1024x768 and 10fps and another cam at 640x480 10fps on 1 64 bit fedora and have the cpu near 90%

and with the jpeg libs i have 10 cams with 5 at 1024x768 10fps and 5 more running at 100xsomething and cpu stays arounf 70-80

this is a 1.6 core duo machine

also in response to the file sys delay try a raid0 array in lvm so you can add and remove volumes easely