Multiple motion detection settings on the same camera
  • Hello,

    My cameras cover quite a big area and I noticed that if I tweak motion detection to catch far away objects then I get a lot of false positives close-up. Similarly if I tweak for close-up motion detection I don't get any alerts for objects further away.

    Therefore I'd like to setup them with two different levels of motion detection sensitivity:
    - High motion sensitivity that covers entire area and triggers recording, but not alerts. Used for occasional reviewing.
    - Lower sensitivity that uses mask to cover close up area (and catches larger motion aka people). Used to trigger recording and real intrusion alerts.

    I understand that I can add the same camera twice in order to achieve this.
    My question is - will this result in double motion detection processing and therefore increased CPU load? Or is the motion detection processed once per (physical) camera and the different settings applied only afterwards saving some of the CPU load?

    Is there some other way to achieve this in a different way? Perhaps using some perspective correction in SecuritySpy?
    Anyone having other/different solution for this?

    Btw. My (Reolink) cameras support low-res and high-res streams and I noticed that SecuritySpy uses significantly (several times) fewer resources when motion detection is enabled on the low-res stream as opposed to the high-res stream. As a result my setup now performs detection on low-res stream and on motion triggers recording of high-res camera stream.
    Are there any plans for SecuritySpy to take advantage of multiple streams automatically?

    thanks,
    Michal
  • Hi Michal,

    I've been [attempting] to do something similar for quite some time. In my case, I use the second instance to capture just the mailbox in front of my home.

    Regarding the CPU usage, I've reduced my frames/sec to between 6 and 8 with the camera firmware settings. I've also reduced the bits/second in the camera as well.

    The resulting video is more than fine for surveillance purposes and my CPU usage for each instance of the same camera is about 16%, leaving plenty for other purposes. (My camera here is a Dahua 3 megapixel). I had tried using the lower bitrate substream as a second instance of the camera, but it didn't seem worth it because the quality of the captured video was relatively poor.

    I'll be interested to see if your setup works regarding small fields of motion detection in a second instance of the same camera works for you.

    I've had a perplexing lack of success with small active detection fields where most of one of the second instance of the camera field is masked out. I've even set the sensitivity to 99 and the motion time to 1/2second or 1 frame. It seems to not trigger capture motion events in small areas reliably.

    In recent posts on this forum, Ben seems to suggest that small capture areas aren't sensitive. (That's been my inference; perhaps I'm wrong about that?) I'm wondering if the algorithm Ben uses just won't work with small fields(?) where masking is a large percentage of the actual visual field.

    As a software suggestion, I'm wondering if Ben could add an additional way of selecting motion detection for small fields- if there were a way of drawing a single polygon in the area of the field that would be sensitive to detection; everything else would be effectively masked out. It's an approach that's sort of the inverse what's currently done. (My old software, EvoCam, used this approach and it worked for small areas of the field; BTW, that was the only thing EvoCam did better than SecuritySpy. LOL )

    The other thing Ben seemed to mention recently is that his algorithm doesn't respond to a security light turning on because it represents a change in the entire field. It's a feature. He indicated that an option to turn this feature off might be included in a future release.

    I'm wondering if this same thing algorithm "feature" is preventing small field from being detected when there are large masks because the change in the detected field is a large percentage of the entire detected field?






  • If you add a camera twice to SecuritySpy using exactly the same settings, SecuritySpy will detect this and it will pull in just one stream from the camera, and will not count the second instance towards the camera license limit. In this case too, there is only one stream being decompressed, and this is the task that uses the most CPU time (much more than the actual motion detection algorithm itself).

    If the second stream is different (e.g. is the sub stream), then two streams will have to be transmitted and decompressed, so in this case the CPU usage should actually be higher than with two full-resolution streams.

    SecuritySpy is not designed to detect very small moving objects in the scene, as these are typically things that shouldn't be detected (leaves moving in the wind etc.). Also, if something is very small in the frame (e.g. a person very far away), you can't see it clearly anyway, and therefore recording it or generating events based on it is typically not useful.

    If you have a situation where you need to record a range of distances in the same location, then you should use two cameras: one with a wide-angle lens that covers short distances, and one with a longer (more zoomed in) lens that covers the far-away area of interest. More info can be found in our blog post How To Achieve Effective Motion Detection.

    Hope this helps.
  • Also, in the future, we may allow different motion-detection settings for Motion Capture vs. Actions, as I think this flexibility would be very useful for many users.
  • Hi Ben, Weatherguy,

    Thanks for suggestions, I made my setup work.

    The low-sensitivity, constrained area detection works reliable, I assume it's because the area is still fairly large and consistent (think bottom half of the image).
    The high-sensitivity settings allow me to record almost all motion without actually having to have 24/7 continuous recording enabled (which saves quite a bit of space for me).

    I also spent some time trying to play with the high- and low- quality streams and I have to say it works really well and costs 1/10th of CPU performance compared to only using the high-quality streams.

    Here's the setup I tried has two 'virtual' cameras per physical camera:
    1) Low quality camera set to substream with resolution 640x360, 10fps (H264 High profile).
    2) High quality camera set to substream with resolution 2560x1440, 30fps (H264 High profile).
    3) LQ camera is setup to perform motion detection, but does not record movies. It's action is to trigger motion event on the HQ camera.
    4) HQ camera does not perform motion detection, only records movies on motion trigger. There's no decoding happening on this camera.

    Results:
    Aforementioned setup with 4 physical cameras (8 'virtual') costs around 7-10% CPU on my mac mini.
    Having only 4 cameras with HQ streams only and performing motion detection on HQ stream costs 75-100% of the CPU time. I can lower this to almost half if I drop to 15fps, but then I lose quite a bit of information from the movies due to low-fps.
    I noticed that changing H264 profiles between baseline, main or high does not affect decoding time.

    So if SecuritySpy would natively support multi-stream cameras, where motion detection is performed on one stream and storage of movie happens from the other stream, we can get:
    1) Much lower CPU cost meaning being able to add more cameras even on lower-end (low power) machines.
    2) Ability to use high-res/high fps movies for archivation without the cost of decoding.

    Do you think this would be possible to add this in the future?

    As far as the different motion detection settings go for capture vs actions - I think this is great idea and would be immediately useful.

    thanks,
    Michal
  • Hi Michal,

    Great to hear you have got your setup working well - using the sub streams in this way is a great idea to reduce CPU usage in certain circumstances.

    The downside to this is that the high-quality streams are not being continuously decoded, so if they are suddenly required at any time there will be a significant delay before decoding can resume and a high-resolution frame will be available. Full-resolution decoded frames may be needed for live viewing in video windows, sending via the web server, sending in email alerts, uploading by FTP etc. So, if you don't use these features frequently then your setup will work great, but if you do use these features frequently (as most users so), then there is a significant downside in not having the high-resolution stream being decoded continuously.

    This is the primary reason why we haven't implemented such a feature in SecuritySpy yet - in most cases it degrades the user experience due to delayed availability of full-resolution decoded frames, which makes the software appear to be slow to respond and makes users think there is something wrong with the software (though we have considered such features previously, and can't rule it out for the future).

    75-100% CPU sounds like a lot, but Activity Monitor reports these figures on a per-core bases. So a 100% CPU usage for a 2-core Mac represents only half of the total CPU resources of the Mac being used by a particular process. For a 4-core Mac this represents only a quarter etc. So, depending on how powerful your Mac is, and how many cores it has, it may be perfectly capable of decoding all your cameras at full resolution without having to set up complicated configurations using substreams and all the disadvantages that go with doing so.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!