2x mjpeg 1600x1200@8fps performance tips
2x mjpeg 1600x1200@8fps performance tips
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.
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.
-
- Posts: 184
- Joined: Tue Oct 14, 2008 5:59 pm
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:)
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:)
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?
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?
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.
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.
see the above forum link thats what it does
Last edited by kingofkya on Fri Nov 13, 2009 12:42 am, edited 1 time in total.
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.
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
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