Subscriber Discussion
Better Way Of Sending Motion Detection Events?
What are the tradeoffs between these forms of sending motion detection events?
1. Motion Detection as per ONVIF :
NVR or CMS will keep asking IP camera about motion detection with in certain intervals using GET API.
Disadvantage: If the motions get detected during the intervals CMS/NVR will get the information during next GET API query. Another thing is CMS/NVR will be busy doing this activity in case of multiple IP cameras are connected
2. Motion Detection as per proprietary methods (some IP cameras support this)
In case of motion detection IP camera will send the information to NVR/CMS. It is expected some listening port to be kept open @ NVR/CMS side which is again to be configured in IP camera which is clumsy. However it seems good implementation as GET is not expected everytime from CMS/NVR. But ONVIF doesn't support the 2nd method
Alex, How do you think ACC would do with the same setup?
C
Detection is done on a secondary CIF stream, not on the full 1080P frame. Another option is to look at the motion vectors in the H.264 stream instead of doing a full decode to YCrCb.
36 -2 MP cams with sub stream doing 20%
and server side motion
I am shocked :)
displaying video on local comp or not ?
I checked Luxriot few years back and it was garbage
may be it better now
36 x 1080p 30fps H264 IP cameras with CIF 30fps sub stream full server side motion analysis (not key frames only) = 20% CPU on i7-3770/FX-8350 with Luxriot 2.4 or HD Witness 2.0.
The argument that VMS server side motion detection is inefficient is weak from the perspective of high effiency VMS solutions as shown above.
Advantage of server side VMS motion analysis:
1. Fast setup and easy, consistent adjustment.
2. consistent results across all cameras
@ Sumit, Axis, Dahua and other top brands follow 1st method
I noticed only one camera (Grandstream) follows 2nd method and they are claiming it is more efficient
John, when you publish your results I hope you can get detail from the VMS companies describing their method of server side motion alarm recording they use and maybe include this information for popular VMS which you are not testing. If a VMS company can demonstrate that the way they implement motion recording allows far greater scaling of cameras on a single server I think it is a big deal. I also would like to know if a VMS implements a unique method of handling motion recording if this could impact ONVIF conformance.
Yes, some efficient methods are mentioned by John. besides these half decoding and reading motion as metadata are few other methods.
Bill, we are actually doing some tests this month on server side VMS motion detection overhead. From what we have already seen, it is likely going to vary depending on the implementation - some just analyze key frames, other analyze the whole stream, some analyze low resolution secondary streams, etc.
I'm not sure the comment that the comment that "effective implementation of motion vectors in VMS will only have minor harware overhead" is accurate. I do not have data to quantify this but I would be interested if someone does.
1st option is helpful from developer point of view. do you have list of camera makes that implement ONVIF way or is this part of Profile-S?
Morten, thanks, that's helpful.
I am not sure if he 'missed' it. Lots of people prefer using camera side motion detection, some VMSes do not support server side, etc. I am certainly not saying it's wrong to do server side but there's a real need for camera side support.
I guess you missed the commonly used third option i.e. server side motion detection. This will be more real time, no alert lost and no camera integration required.
Yes this increases VMS server side CPU, but effective implementation of motion vectors in VMS will only have minor hardware overhead.
As far as I understand, the polling mechanism used in Onvif is similar to "long polling" (see this wiki entry), so it's not completely crap. I still, theoretically, prefer the camera push, but who want's to deal with hundreds of different drivers and firmwares (plus any NAT issues you may encounter in larger systems).
Basically this comes down to whether the IP camera pushes motion detection events (method #2 above) or waits for devices to poll it (method #1 above).
I am not familiar with ONVIF's motion detection implementation but in general, pushing is better as it is typical faster and lower traffic volume than polling.
Newest Discussions
| Discussion | Posts | Latest |
|---|---|---|
|
Started by
Brian Rhodes
|
1
|
1 minute by Brian Rhodes |
|
Started by
John Honovich
|
1
|
less than a minute by John Honovich |
|
Started by
John Honovich
|
1
|
less than a minute by John Honovich |
|
Started by
John Honovich
|
23
|
less than a minute by Undisclosed Integrator #4 |
|
Started by
John Honovich
|
1
|
less than a minute by John Honovich |
