day/night IP bandwidth load

[zd59]

Hi!

I have one 3MP and one 4MP cameras both with IR LEDs. They are confugured to "modect" on low stream (one VGA the other PAL resolution).
Both high streams are "nodect" and each is linked to its low stream modect. So movement is on low stream, recording of events on low & high streams.
All streams are ffmpeg RTSP H.264.
Noticed very interesting "feature" - All four streams are around 1MB/s over the day, but DOUBLE to 2MB/s over the night (when autoswitch to "night mode" - black and white with IR ilumination). And so doubles the computer load. I'm planing to add two cameras to cover all place around the house.
The night load would overload the system.
Have anyone eperienced this situation and found any solution. The problem is low light visibility. If I reduce resolution over night, this get worse.

The other question: Is it possible to achive recording of events only on linked hires streams, lowres streams only detect movements, but recording is off?
That way I would offload the system and save space on disk.

Debian stretch & ZM-1.30
The system monitor used is excellent http://www.monitorix.org

Regards to all!

[benf]

FWIW I find the opposite - at night the traffic drops by around 30% from the cameras I have and they also have separate IR illumination.

What could drive up the amount of data is if the camera is doing any processing to the night images, eg to increase contrast or brightness where the image has a lot of noise which isn't unusual for a low light still.

Would be worth looking through the Camera settings and seexperiment to see if any adjustments there make a difference to the size and volume of traffic whilst not impacting the picture quality too much.

[zd59]

Hi!

Night picture processing by camera can not be the reason for increased network trafic, as all is done by camera itself.
Increased trafic by night it very strange, as gray video do not have a colour info and as such, supposed to have lower IP traffic.
Noticed that traffic increase only on Tiandy camera, on Dahua not. Both have set 3MP h.264 stream and same settings.
A little improvement (15% lower traffic) was when I selected SVC option in h.264 stream settings (Tiandy only).

Tiandy camera is garbage, that works good only alone (pure its own web access). The bought camera package included only the camera and hardware install manual. No user manual, no drivers.. Lucky me, I am a technician in the field to deal with. Their WEB site is useless - no firmware, no descriptions about streams access, nothing. On the web can not be found any usefull info about this manufacturer and its cameras. Stream access with ffmpeg/VLC was a pain, wild guess.. And not to mention "bubles" in night IR lightning. Can not be removed (found and read instructions on the WEB). No dome camera again!
I was new there, did not know about IP cameras. Now I know how to select a proper camera.

When you try to get high resolution stream with any application, you got problems. Camera is 4MP H.265, but this works only when access its own WEB server over browser (windows plugin, so limited to Window$, no linux access). VLC, ffmpeg, ZoneMinder maximum is 3MP h.264 with drops of connect of high stream (none a day to every two minutes). Low stream (PAL) works perfect.
Looks like they (manufacturer) deliberately cripled high stream when camera detect streaming to any, except browser plugin or Tiandy NVR!

[jerrynavarete]

Is there a difference between a day and night bandwidth load?

[zd59]

Yes, that is the reason for my post.
Read the first post carefully.
You can see the difference in IP traffic and one of four CPU load at attached Monitorix log pictures for 24 hours. From 19. to 20. 7. 2017.
You can clearly see, when the night mode with IR LEDs switch on (high IP traffic and high CPU load).
The most strange is, that the huge part of a traffic produce one camera of two. They are from different manufacturers.
Thinking of of a bug in that camera software.

[Baylink]

I don't find it unusual that IP cameras would generate more network traffic at night -- cameras are noisier in low light, and unless the camera noise-reduces *before MPEG encoding*, you're going to see the results as lower compression, and hence, higher datarate.

In the day, the incoming light swamps the sensor noise and it's not a problem.

[zd59]

Thanks Baylink!

That's the reason, I would never think of.
Looks like this vendor did not reduce night noise successfully. The other camera from different vendor is excellent regarding this issue.
Will try some settings on cameras web page - trade off regarding night sharpness, contrast.. Already set all to best, but never looking IP traffic at the same time.

[Baylink]

The more expensive the camera, the higher quality the processing, and probably the larger and hence quieter the sensor... and so the smaller files in MPEG compression.

[zd59]

Point for you - I looked for a resolution and price only.
After a year of experiments & use, now I know how tu buy next one.
The first failure was sphere plastic shield and so "night bubbles".
Now I have a list of "not to" features.

[zd59]

Sam Smith is this an advertisement or joke?
Here we discuss about network IP cameras for a video surveillance.
You suggested https://en.wikipedia.org/wiki/Nikon_D3100 that is camera for photo shooting.

[mikb]

Hmmm. Joined 4 minutes before first posting, to resurrect an old thread, with an irrelevant reply.

If there was a referral link to buy the D3100 at amazon (for a kickback to the link poster), then I'd say it's spam. Otherwise, it's just very badly targetted advertising.

ETA: Of course the "!" button is back to "404: Not Found", so it's hard to flag it up

[SteveGilvarry]

Dealt with now, to get someone to look at servers

[zd59]

Dealt with now, to get someone to look at servers

Do not quite understand that. What do you mean by that?
As I understand cameras by now, the problem is huge noise rise, when camera switch from color to B/W and turn on IR illumination at dark.
Then all depends on camera quality, how successfully it reduce video noise..
Zoneminder have no influence with amount of data transfer. It only accepts the data camera sends.

[mikb]

Steve's response was in relation to an interloping posting by Spam Smith (now deleted), and my subsequent mention that the "Report Spam" button was broken. It is *that* which is fixed (by tinkering with servers). Thanks Steve.

[SteveGilvarry]

Yes sorry was referring to the spammer, should have been clearer, was on my phone and doing it quickly. Just wanted to leave something so you knew I deleted him and his post.
On topic yes the data stream is what the camera controls, CPU is probably zm coping with that increase in data. But it is interesting as I have seen this with cameras also, where night time resulted in larger files on passthrough.
CPU must kick up as a result, I was thinking it might work less as getting less compressed data. But then thinking about it more, I think it will be getting more pixel changes to have to decode.