AXIS Camera Bandwidth At Night

[lwiscovitch]

We've got four cameras at two locations being monitoring by ZoneMinder...The cameras are set to "nodect" in ZM and the camera's perform the motion detection on the device and send an alert to ZM whenever motion is detected.

What I'm noticing is that when the office is closed and the lights are off the bandwidth for all the cameras rises to consistent level until the morning when the sun/lights are back. I think this is because of the night/ir vision.

We don't want to stop monitoring during those hours, but are there any hints/tips/tricks to minimizing the bandwidth during those times? I've looked through the camera's configs and haven't found anything that jumps out at me.

The big reason this is a problem is that if our primary WAN goes down our backup WAN is not very fast (DSL) and we don't want the camera's consuming all the bandwidth (We have other services {voip, vpn, etc} that share the bandwidth).

One thing I tried was limiting the normal FPS to 1FPS but the alarm FPS to 5FPS with the idea that it'll monitor at 1FPS and then record at 5FPS...Of course this didn't work as expected soI went back to a matching 5FPS for both. With this config everything is great except the night time bandwidth issue.

[asker]

I'll try and put some thoughts forward. But first, let's make sure I understand your predicament accurately. Would appreciate if you could ack/nack each point:

a) You have 4 cameras set to "Nodect" (_not_ Modect) . That means ZM is not doing motion detection. You are using zmtrigger.pl to cause a recording after your camera detects motion, inside its own hardware -- so ZM is sitting idle till it gets a notification from some app/script to start recording

b) You comment on primary/secondary WAN seems to indicate that the ZoneMinder software and your cameras are not in the same LAN. Correct? If it were, primary and secondary WAN would not matter as the recording would be over the LAN

c) Your core predicament seems to be that during daylight, the camera's motion detection works reasonably well, but at night, it seems to be in overdrive detecting motion a lot

If the answer to a) and b) is "Yup, that's pretty much it" then I'd conclude that you might have 3 options:
1) Change the sensitivity in-camera for motion detection - it is entirely possible that lights/flying bugs/etc are triggering constant recordings - how to tune it would be upto your camera settings
2) Don't use in-camera motion. Use ZoneMinder's "modect" mode and define zones properly. They are much more powerful. I too, started with in-camera motion but moved to ZM's motion detection once I got a hang of things. See http://www.zoneminder.com/wiki/index.ph ... rver_14.04 and take a look at the "Understanding ZoneMinder's zoning system" link
3) Your camera is special. It's a Ghost buster detector. Put it for on eBay for a million bucks.

Finally, please don't rate limit FPS within ZM to any value lower than the rate limit in-camera. It causes a world of pain that has been discussed in other threads.

We've got four cameras at two locations being monitoring by ZoneMinder...The cameras are set to "nodect" in ZM and the camera's perform the motion detection on the device and send an alert to ZM whenever motion is detected.

What I'm noticing is that when the office is closed and the lights are off the bandwidth for all the cameras rises to consistent level until the morning when the sun/lights are back. I think this is because of the night/ir vision.

We don't want to stop monitoring during those hours, but are there any hints/tips/tricks to minimizing the bandwidth during those times? I've looked through the camera's configs and haven't found anything that jumps out at me.

The big reason this is a problem is that if our primary WAN goes down our backup WAN is not very fast (DSL) and we don't want the camera's consuming all the bandwidth (We have other services {voip, vpn, etc} that share the bandwidth).

One thing I tried was limiting the normal FPS to 1FPS but the alarm FPS to 5FPS with the idea that it'll monitor at 1FPS and then record at 5FPS...Of course this didn't work as expected soI went back to a matching 5FPS for both. With this config everything is great except the night time bandwidth issue.

[lwiscovitch]

A) Yes

B) Yes, we have three sites all linked by VPN...Two cameras are at two sites, and ZM is in the third (Datacenter). Each site has a nice primary WAN but the secondary ones are weak (DSL) due to availability issues.

C) Almost...It's not really recording much, but it's just taking more bandwidth. I have a feeling it's something with the compression...The low light is causing more "noise" in the picture, which means it can't compress as efficiently. We do get some random recordings when someone drives through the parking lot and the headlights flood the recording area, but that was expected.

I'll look into adjusting the sensitivity levels of the cameras, as well as letting ZM handle the motion detection. I'm continuing an existing deployment where "nodect" was already in play (I think the idea was to free of resources on ZM by offloading the motion detection to the cameras).

I have ZM using the camera's H.264 streams instead of MJPEG...I took the built-in "Low Bandwidth" profile and modified it to only streams at 5FPS...Not sure if that impacts this at all. When we did MJPEG the bandwidth was much higher.

[asker]

C) Almost...It's not really recording much, but it's just taking more bandwidth. I have a feeling it's something with the compression...The low light is causing more "noise" in the picture, which means it can't compress as efficiently. We do get some random recordings when someone drives through the parking lot and the headlights flood the recording area, but that was expected.
I have ZM using the camera's H.264 streams instead of MJPEG...I took the built-in "Low Bandwidth" profile and modified it to only streams at 5FPS...Not sure if that impacts this at all. When we did MJPEG the bandwidth was much higher.

Ah! My apologies. I misunderstood 'bandwidth' to mean 'more recording'. Your issue seems to be the RTSP stream gets 'heavier' from the camera at night possibly due to more 'data' in each frame. Yes? Interesting. If so, moving to ZM zones won't help.

Out of curiosity,
1) Which specific camera do you have? (updated: your subject said AXIS. Which model?)
2) What is the magnitude of bandwidth difference?

Some thoughts for different options (can't say it will really help unless you try)
a) Define two run states in ZM -->Define two different video streams in your camera - adjust key frames/bit rate etc - switch to different streams in daytime and night via cron/runstates
b) If you are using ffmpeg, take a look to see if you can optimize input parameters to tweak it

[asker]

It seems Axis cameras allow for adding compression parameters in the video URL for RTSP which is pretty cool.
http://custforum.axis.com/viewtopic.php ... fdfcf1b1a6

So I'd probably either:
a) Create two RTSP streams (one for night and one for day) in-camera and use run-states of ZM to switch between the two
b) Create two RTSP sources within ZM (one for night and one for day) and use run-states of ZM to switch between the two

I don't own an Axis, but you may want to play with:
1) The profile (Main vs. Base)
2) Compression
3) Any other parameters it offers - to get to an RTSP bw that is acceptable for night and then reflect that setting in your run state

[lwiscovitch]

Three of them are P1354 and the fourth is P1343

I'll check the URL parameters to see if they help, otherwise I might look into those run-states you're talking about...