Who is doing motion detection? the camera or the NVR

[aster1x]

All the latest IP cameras including HIKVision are doing motion detection and they are emailing a few pics upon detection.
Also I understand that IP cameras are creating the video stream readily available to an internet connection through the camera UI and an Internet browser.

However, when any IP camera is connected to an NVR (the integrated NVR switch), who is doing the motion detection, the camera or the NVR?
The preparation of video streams is a serious CPU intensive work and it is done only by the camera. The NVR does not create the video stream.

I have a HIK camera connected to a HIK NVR through the integrated switch. The camera cannot send emails (and take NTP updates or DDNS updates) because the NVR does not allow it. If the motion detection is initially disabled in the camera and then we enable the motion detection in the NVR, then the motion is also enabled in the camera and the email is send from the NVR. In this case the camera CPU wastes processing to do a motion detection that is not used by anything. Isn't this a waste of resources?
Therefore I conclude that both camera and NVR do motion detection but I cannot confirm it because the camera is not really connected to the outside world.

Would n't be better to control features such as motion detection separately and indepentently in the camera and in the NVR?

Is there a utility to report somehow the camera (or even the NVR) CPU processing load?

 

[dr.]

Cameras do everything. They are basically ARM linux boxes. Your NVR just acts as a NAS box with a fancy client GUI. There's no reason to measure processing load which is why NVR's are just measured in how much data can be processed from the cameras i.e. 8 channel box that can do 1080p@30fps up to 50Mbps total. CPU power is pretty meaninless.

The NVR is just a GUI to display the live view client and to show the camera settings. Enabling/disabling motion detection on NVR just turns it on/off on the camera. NVR does nothing.

Email, NTP, or any network service is forwarded/diverted to the NVR because the devices are behind a non-public facing network when connected to an NVR appliance. That is a security feature.

 

[aster1x]

Cameras do everything. They are basically ARM linux boxes. Your NVR just acts as a NAS box with a fancy client GUI. There's no reason to measure processing load which is why NVR's are just measured in how much data can be processed from the cameras i.e. 8 channel box that can do 1080p@30fps up to 50Mbps total. CPU power is pretty meaninless.

The NVR is just a GUI to display the live view client and to show the camera settings. Enabling/disabling motion detection on NVR just turns it on/off on the camera. NVR does nothing.

OK I accept your reasoning and I would add that an NVR shouldn't care about the format of the video i.e. frames, resolution etc, we should only be interested about the bandwidth transfer capability i.e. the Mbps of recording and playingback. Specifying an NVR (that deos not do enconding) in terms of frames and resolution is totally meaningless.

However since the camera produces two streams, one main usually high resolution for recording and one substream for WAN access through the (usually) low bandwidth 800kbps upload channel of the ADSL, then how does the NVR know there is motion detection in order to start recording and how does it change the recording quality from the main stream (usually specified at low fps and bitrate to preserve hard disk space during continuous recording) to a higher resolution, fps and bitrate recording (completely differently from the substream)?

Does the camera pass a message to the NVR about the motion detection event? If YES then who provides the "detection" stream with the different resolution and quality?

Also if the NVR does not do any procesing and reencoding then obviously the NVR CPU load may be meaningful BUT the switching capablity of the NVR is even more important. Is this measureable somehow?

In this case since the camera does all the encoding and scene analysis for motion detection then it is more usefull to measure and know the camera CPU load. Is this possible?

In other words if we assume that the camera is connected to a LAN based VMS, then how may detection features and processing can the camera do? There must be a limit depending on the capabilities of the camera CPU.

Email, NTP, or any network service is forwarded/diverted to the NVR because the devices are behind a non-public facing network when connected to an NVR appliance. That is a security feature.

I totaly agree with your explanation and I also would prefer NOT to have the camera traffic broadcasting in my main LAN. However I have confirmed that when I connected with a patch cable the NVR PoE switch with the LAN port switch, then the cameras could see the main LAN and forward emails, motion detection alerts, NTP and DDNS updates properly. When I disconnected the NVR PoE switch from the LAN switch then there is no communication of the cameras with the LAN and therefore there is no email capability, NTP and DDNS updating since the cameras belong to a different subnetwork (as you mention correctly). The only way to access the camera interface is through the port forwarding mechanism of the latest NVR firmware 2.3.9 and the related function "Virtual Host".

 

[taylor]

The cameras have a frame rate and bandwidth limit and I presume it's because Hikvision knows the limit of those cameras. For instance I have one cameras with a 30fps limit and others with 25fps at 1080p. Knowing the CPU load may be helpful, but I'm under the assumption that the camera can handle it. Setting iFrame interval too high, with quality, frames, and resolution all at max, you might get dropped frames if you peg the CPU. I'm not really sure but I've not observed anything that appears to be a taxed camera CPU.

From what I understand, the camera treats the NVR as a NAS and starts saving video to it like it's a remote hard drive. I don't know the protocol (yet.) It's not the NVR doing anything except being there for the camera to send it's video to. I'd like to verify this, though.

For my setup I bought a 16-port POE injector and a 24-port Gigabit switch. I'm running all cameras into the switch (through the POE injector) then running a single gigabit out of the switch to the NVR. My NVR has a 80Mbps limit. My switch is also part of my general network with other things connected. I did it this way for 2 reasons:
1) I want direct access to the cameras independent of the NVR. Just because. I hadn't considered the security aspect but I'm not really concerned with that.
2) The main reason is because I don't want my camera ethernet cables to terminate in the same place as my NVR. The POE injector and switch where I'm running all of my camera ethernet cables are in the garage at a patch panel. The NVR is located in the house. Unless I want to put the NVR in the garage, I can't use the NVR's POE ports. Or I'd have to run them to the place that the NVR sits which doesn't seem pretty to me.
I haven't even unboxed the NVR yet. I plan to do that in the next day or two. So I hope my setup is going to work.

My solution is at an added cost, mind you. A 16-port POE injector, 24 port switch (Gigabit even,) patch panel, 32 short ethernet patch cables.
Note that he gigabit switch isn't necessary for the camera system alone since each camera is a max of 8Mbps and have 100Base-T ethernet only, and my NVR has a 80Mbps limit. But my switch is for whole-house use also and wanted the line from the switch to the NVR to be gigabit.

Needless to say I just got all of my equipment and I'm just starting installation so I'm not even there yet. I just thought I could shed some light on the subject.

 

[aster1x]

My solution is at an added cost, mind you. A 16-port POE injector, 24 port switch (Gigabit even,) patch panel, 32 short ethernet patch cables.
Note that he gigabit switch isn't necessary for the camera system alone since each camera is a max of 8Mbps and have 100Base-T ethernet only, and my NVR has a 80Mbps limit. But my switch is for whole-house use also and wanted the line from the switch to the NVR to be gigabit.

Your post is a bit irrelevant with my initial posting but I would like to comment that your setup is the proper configuration (to my taste!!) with one assumption that I urge you to consider. You say that the gigaswitch will also handle the rest of the house internet needs. Are you sure that your giga switch has enough power to switch independently all your cameras (if i recall from another post 10 cameras*8Mbps=80Mbps streaming not store and forward) PLUS your household needs? If your gigaswitch can create VLANS then you are almost OK. The ideal way would be the gigaswitch to have routing abilities so that you create a VLAN between the cameras and then NVR and another VLAN between the NVR and the reset of the house. This is the effect that the integrated PoE switch in the NVR actually does, it isolates securily the cameras from the rest of the LAN and at the same time it allows LAN requests to be forwarded to the cameras with the Virtual Host feature. By the way which NVR will you be using?

 

[catseyenu]

In this case since the camera does all the encoding and scene analysis for motion detection then it is more usefull to measure and know the camera CPU load. Is this possible?

CBX was able pulled load averages, you might ask him.

http://www.cctvforum.com/viewtopic.php?p=249164#p249164

 

[aster1x]

CBX was able pulled load averages, you might ask him.

http://www.cctvforum.com/viewtopic.php?p=249164#p249164

Thanks for the notice. Altghough I have read most posts in many forum, obviously I missed that one. And yes I have asked CBX but he is bus with tegion coding support issues.

 

[catseyenu]

I was wondering why he has not been sharing as much lately...
There's quite a bit of catching up to be done if you're like me and came into the Hik world in the last 2-3 months. The older firmware update threads are particularly juicy.

 

[taylor]

Your post is a bit irrelevant with my initial posting but I would like to comment that your setup is the proper configuration (to my taste!!) with one assumption that I urge you to consider. You say that the gigaswitch will also handle the rest of the house internet needs. Are you sure that your giga switch has enough power to switch independently all your cameras (if i recall from another post 10 cameras*8Mbps=80Mbps streaming not store and forward) PLUS your household needs? If your gigaswitch can create VLANS then you are almost OK. The ideal way would be the gigaswitch to have routing abilities so that you create a VLAN between the cameras and then NVR and another VLAN between the NVR and the reset of the house. This is the effect that the integrated PoE switch in the NVR actually does, it isolates securily the cameras from the rest of the LAN and at the same time it allows LAN requests to be forwarded to the cameras with the Virtual Host feature. By the way which NVR will you be using?

I see what you're saying. VLANs aren't necessary unless you want security (and I am explicitly avoiding that security.) The way the switch works all camera and NVR traffic is isolated between those 11 ports. It's not 1Gbps total for the whole switch (like a Hub,) it's 1Gbps per port. A VLAN will only serve to isolate broadcast traffic such as DHCP, multicast, as well as prevent direct subnet access (mostly for security.) If you're going to set your cameras to multicast, this whole discussion changes otherwise for actual total raw capacity of bits, a managed switch with VLAN isn't going to improve anything over an unmanaged switch like this one which already routes traffic between ports efficiently. That's the point of a switch.

10 ports at 4Mbps each. 1 port 80Mbps. That's 160Mbps between those 11 ports, and that doesn't affect the other ports.
Let's say I have 5 rooms of the house on ports 12, 13, 14, 15, 16, plus a wireless access point on 17. Then I want to transfer a file from room to room (port 12 to 13), they can still do it at 1Gbps while ports 1-11 are doing 160Gbps sustained. At the same time someone can be downloading from the internet over wireless between the router on 15 and the wireless AP on 16 (Internet is 50 Mbps.)
The inefficiency only comes into play when I have multiple things in each room trying to access other rooms. Now traffic is sharing a common ports.

Hypothetically let's say I put that NVR in the living room is on port 12. In that living room is another switch, so port 12 is carrying the NVR traffic as well as all other traffic from that room (Xbox, playstation, Roku, etc.) Even in that situation, the NVR is only using 8% of the total bandwidth. Latency (XBOX) shouldn't start increasing into play until I reach well over 50% of that port capacity (500Mbps.)

As it is, the NVR has it's own ethernet run to the room where it is not shared. There is a separate one for everything else. So with my setup the usual 160Mbps of traffic remains on it's ports.

It's a TP-LINK TL-SG1024 which like any 24 port Gigabit switch *advertises* 48Gbps total capacity. That's the theoretical limit where 1Gbps between ports 1-2, 3-4, 4-5, etc. (24*2Gbps - bi directional) all at the same time.

Honestly this all could work with even a 100 base T switch. The problem comes in when I want to remotely stream from the NVR to a computer. Now the NVR has 80Mbps incoming, and another undetermined Mbps going back out to the PC. Even then that's 100Mbps per direction, so it's still possible. But I certainly don't like to run that close to the limit.

Initially I was looking for a 16 port 100 base-T (cameras are 100Base-T ) POE switch with gigabit uplink just for the cameras. The problem is all of the ones I found only had 8 POE ports, the other 8 non-powered, and they were very expensive. It was cheaper to get a 24-port Gigabit and just get a 16-port POE injector to go on top of that.
I could install two switches. 1st for the cameras and NVR, the 2nd switch for the house then link the two. But that doesn't gain me anything and it's less efficient than one big switch.

I GET the concern which is to overload the switch and do things the most efficiently. I don't want my Halo games to lag . I do have peripheral switches and dedicated ethernet where I think it helps, but in this case with this switch, I think it'll work well.

The NVR is Hikvision DS-7716NI-SP/16
I contemplated getting the EYEsurv ESDV-NVRXPRO-16 16 Channel NVR which can take up to 160Mbps input. But it's a Dahua which theoretically will work with ONVIF and supposedly does work fine with Hik, but I wanted to play it (hopefully safer) by sticking to all Hikvision products (IDK.)

One other note. I'll be using motion detection on the cameras. I understand they're only sending their stream when they're triggered and recording. So it won't be 80Mbps sustained 24/7 unless all cameras trigger at the same time. Either way I have to account for that happening. But I am fully ignorant on this detail until I unbox this thing and set it up.

You got me all curious now and I'm going to dig in tonight.

 

[dr.]

...
However since the camera produces two streams, one main usually high resolution for recording and one substream for WAN access through the (usually) low bandwidth 800kbps upload channel of the ADSL, then how does the NVR know there is motion detection in order to start recording and how does it change the recording quality from the main stream (usually specified at low fps and bitrate to preserve hard disk space during continuous recording) to a higher resolution, fps and bitrate recording (completely differently from the substream)?

Does the camera pass a message to the NVR about the motion detection event? If YES then who provides the "detection" stream with the different resolution and quality?

Also if the NVR does not do any procesing and reencoding then obviously the NVR CPU load may be meaningful BUT the switching capablity of the NVR is even more important. Is this measureable somehow?

In this case since the camera does all the encoding and scene analysis for motion detection then it is more usefull to measure and know the camera CPU load. Is this possible?

In other words if we assume that the camera is connected to a LAN based VMS, then how may detection features and processing can the camera do? There must be a limit depending on the capabilities of the camera CPU.

NVR "knows" nothing beyond what the cameras tell it. The streams are there whether you are looking at them or not.

Camera: Motion detected on cam1 in defined regions.
NVR: Okay. Display alarm icon. Recording X seconds of main stream.

You can see the CPU "limits" of the cameras right on hikvision's site. Max users, detection zones (8 on average), bitrates, etc. I don't see where you are going with this thought process. All the high CPU/GPU tasks can't be changed or modded as the source code will NEVER be released. At best you can run some scripts on the camera but those won't tax the CPU at all. Yes, with any tech product the cheap product likely has the same chip as the expensive units--just artificially crippled through bins or firmware.

 

[aster1x]

@dr.

OK I agree with what you are saying but you have not answered on my question "how does it change the recording quality from the main stream (usually specified at low fps and bitrate to preserve hard disk space during continuous recording) to a higher resolution, fps and bitrate recording (completely differently from the substream)?"

I remind you that the HIK NVR firmware 2.3.9 allows you to define the specifications of the video streaming for continuous recording and different specifications for recording the video during motion detection.
I realised this when I had set the camera and the NVR for continuous recording at the highest possible quality, resolution=3Mpixels @20fps @8Mbps and then I realised during playback that the scenes during motion detection were heavily pixelated because the motion detection stream defined in the NVR was set at very low quality (1Mpixel,@10fps,@512kbps).

Does the HIK NVR requests from the camea to change the video stream with the settings defined in the NVR for motion detection, after it receives the motion triggering from the camera ???

 

[dr.]

Does the main stream change? Should be very simple to test if you are this curious. Watch the direct feed coming from the camera in VLC or internet browser. My guess is that the NVR just dumps that extra info and the main stream stays at that full resolution. Once motion is triggered, it stops doing that. Again, the NVR is pretty meaninless and "forgetting" information.

I still have no idea where you are going with this as your questions don't sound like idle curiosity. It seems like you're trying to get the cameras/NVR to do other things. Outside of running simple scripts on camera, you're going to hit a brick wall with the binary firmware/drivers.

 

[aster1x]

@dr.
Well I was wathing the live view scene and it was in the highest quality as specified in the main stream, even during the motion scene. However when I downloaded the scene file from the NVR and played it back wih VLC, I noticed that when the motion was detected the whole scene quality changed at the "motion detection quality parameters" set IN the NVR. That means that the NVR is not opeating just as a "dump" NAS but it does some processing as well, contrary to your initial statement that an NVR is just a NAS. Now if th NVR does this for all cameras, this sums up to some additional processing.

Therefore my curiosity is to understand who is doing what in order to understand better the limits of the capabilities of the system and solve problems.

In any case thank you for your comments.

 

[vimes]

I haven't has my six Hikvision IP cameras or my Hikvision 7608 NVR for that long nut I was also wondering if the NVR will override those settings of the camera, for motion detection, or, if the camera settings are considered to be more sensitive for triggering an event, and thus supplement those of the NVR...?

Both my NVR and cameras have their latest firmware....






the above is for the NVR and below is for one of my cams...

...now the camera allows setting for MD over that of the NVR, like in Expert mode such as switching and proportion of. And there are other settings like line crossing detection etc. If those are selected and the option to trigger the channel is used I wonder if they will be recorded to the NVR or would it be ignored as no storage option has been defined, as it is connected to the NVR....?

I am using the iVMS-4200 Client and the web browser over that of the NVR as that is hidden and thus does not have a monitor etc attached to it.

I need to find time to play a little more to find these things out

 

[aster1x]

@vimes
Mind you that the NVR native interface has certain features such as motion detection video quality parameters that do not appear in the NVR web interface and in the camera interface. Also the NVR does not have other features such as the Virtual Host that appears only in the NVR web interface. As a conclusion the NVR web interface and the NVR native inteface and the camera web interface DO NOT present the same functionality to the user. It seems to me that the software development between the different HIK products and subsytems is not synchronised in time and functionality.

 

[vimes]

@vimes
Mind you that the NVR native interface has certain features such as motion detection video quality parameters that do not appear in the NVR web interface and in the camera interface. Also the NVR does not have other features such as the Virtual Host that appears only in the NVR web interface. As a conclusion the NVR web interface and the NVR native inteface and the camera web interface DO NOT present the same functionality to the user. It seems to me that the software development between the different HIK products and subsytems is not synchronised in time and functionality.

Good point

As I have hardly used the NVR interface I would not have known that. I do agree with you that the interface and general functionality of each of the types of client are not harmonised between the applications. I would have expected the iVMS-4200 Client to have had the same level of functionality to that of the NVR's own interface and yet could understand that the cameras themselves, as Hikvision like to give them their own almost NVR type functionality, to have their own storage and email options etc but the line cross drawing etc should be there in the iVMS-4200 Client. I can't remember if that, for example, is in the NVR's own interface.

 

[aster1x]

@vimes
No the line crossing detection, traversal plane crossing and face detection do not appear in the NVR any interface. Also please always specify the firmware version you have in any product because features come and go without proper documentation, see the mess they have created with three versions of the camera firmare 5.1.6 and different functionality between version 5.1.6 and 5.2.0. Also the NVR has five (5) versions of firmware 2.3.7!!!


Additionally beware that if you open say the web interface and the native NVR interface, the last interface that you close will OVERWRITE the settings of the previous interface closed. This is especially confusing when you change ports between the different interfaces. All push the button save at ALL changes you make at the last interface closed. It drove me crazy when I was customizing my ports and in some instances the remote (WAN) viewing was functional and in other instances it was functional. There have several forumdocumentations about port problems attributed to which interface was the last closed.

Good luck as well and document eveything you do with accuracy because even the minute detail makes a lot of difference in the proper functionality.

 

[catseyenu]

@vimes
No the line crossing detection, traversal plane crossing and face detection do not appear in the NVR any interface. Also please always specify the firmware version you have in any product because features come and go without proper documentation, see the mess they have created with three versions of the camera firmare 5.1.6 and different functionality between version 5.1.6 and 5.2.0. Also the NVR has five (5) versions of firmware 2.3.7!!!

A clusterf$ck of programing for sure...
The newer NVR firmware seems to have began closing this gap but you will need the neutered 5.20 firmware on the camera.
I can't believe more CBX region fix customers haven't stepped up to ask for the fixed 5.20 firmware than what's been reported.
Are there that few of us using the NVR or are they holding out hoping that Hik will return the features in their next release?

Additionally beware that if you open say the web interface and the native NVR interface, the last interface that you close will OVERWRITE the settings of the previous interface closed. This is especially confusing when you change ports between the different interfaces. All push the button save at ALL changes you make at the last interface closed. It drove me crazy when I was customizing my ports and in some instances the remote (WAN) viewing was functional and in other instances it was functional. There have several forumdocumentations about port problems attributed to which interface was the last closed.

Good luck as well and document eveything you do with accuracy because even the minute detail makes a lot of difference in the proper functionality.

Spent hours testing and dialing in settings, closed the interfaces and went to bed only to find everything is wack the next day?
Welcome to the Twilight Zone.
I'd be willing to go in on buying CBX an NVR if he's willing to fix it.
These are still very good bang for the buck units, it's just frustrating to have very fixable flaws in a few of the software features.

 

[vimes]

@vimes
No the line crossing detection, traversal plane crossing and face detection do not appear in the NVR any interface. Also please always specify the firmware version you have in any product because features come and go without proper documentation, see the mess they have created with three versions of the camera firmare 5.1.6 and different functionality between version 5.1.6 and 5.2.0. Also the NVR has five (5) versions of firmware 2.3.7!!!


Additionally beware that if you open say the web interface and the native NVR interface, the last interface that you close will OVERWRITE the settings of the previous interface closed. This is especially confusing when you change ports between the different interfaces. All push the button save at ALL changes you make at the last interface closed. It drove me crazy when I was customizing my ports and in some instances the remote (WAN) viewing was functional and in other instances it was functional. There have several forumdocumentations about port problems attributed to which interface was the last closed.

Good luck as well and document eveything you do with accuracy because even the minute detail makes a lot of difference in the proper functionality.

I did note that I was on the latest firmware for each device, 2.3.9 for the NVR and then 5.2.0 for the cameras. But my points were not, necessarily, related to tha tof the firmware but the overlapping inconsistencies between the interfaces of their devices. I had hoped that by sticking to one manufacturer the UI's and functionality would have been more harmonised across the Cameras, NVR's their firmware and client software, for both Windows and the Android platform.

As well as noting things I have started making certain adjustments to one camera at a time to see what those differences change to the recordings etc. But as the NVR is well hidden etc I have to rely on either the Web interface or that of the 4200 client, and I'm trying to use the latter.

A clusterf$ck of programing for sure...
The newer NVR firmware seems to have began closing this gap but you will need the neutered 5.20 firmware on the camera.
I can't believe more CBX region fix customers haven't stepped up to ask for the fixed 5.20 firmware than what's been reported.
Are there that few of us using the NVR or are they holding out hoping that Hik will return the features in their next release?
Spent hours testing and dialing in settings, closed the interfaces and went to bed only to find everything is wack the next day?
Welcome to the Twilight Zone.
I'd be willing to go in on buying CBX an NVR if he's willing to fix it.
These are still very good bang for the buck units, it's just frustrating to have very fixable flaws in a few of the software features.

I asked him directly about this and he told me that it would be a lot of work and that only one other user had requested it. I know that he provisionally made an offer to provide this, if there was demand, but I have not read anything more about that.
It took me a while to realise that the face detection aspect of the 5.1.6 firmware didn't work and it wasn't just me not understanding its functionality, so I guess tha tI will not be missing that..!

I have been in contact with one person at Hikvison, in regards to the interface / UI in their range of software and requested an event marker within the timeline of recordings, he told me that he would speak to R&D to see if it could be included. Maybe if enough people pointed out these issues to Hikvision support then something might change...?

 

[aster1x]

A clusterf$ck of programing for sure...
The newer NVR firmware seems to have began closing this gap but you will need the neutered 5.20 firmware on the camera.

Why do you say this? AFAIK the camera firmware version 5.2.0 has less features than version 5.1.6. Beginning with the NVR version 2.3.8 (note the chang ein the background image of the NVR native interace and the reorganisation of the menu items) they have introduced different motion detection video quality parameters that do not exist as a stream in the camera firmwares andin version 2.3.9 beta and onwards they have introduced the Virtual Host feature in order to acces the camera interface without rewiring the camera connection. I believe the virtual host was the most important improvement as far as remote management is concerned. Therefore NVR firmwares from 2.3.8 and onwards ignore completely all the best of the features in the latest camera firmwares.

Therefore why do you say that the newer NVR firmware requires the latest camera 5.2 firmware? Which feature of the camera is utilised functionally from the latest NVR firmwares?

P.S. I used very briefly the camera firmwares 5.1.0 up to 5.1.6 because I jumped very quickly to the camera firmware 5.1.6 from the original 5.0.2 (and from what I am reading, there is no useful feature in 5.2.0). Also I jumped from the NVR firmware 2.3.7 December 2013 edition to the 2.3.8 briefly and then to 2.3.9 beta.