HikVision DS-2CD2032-I Corrupt Video Feed
  • I am currently testing out SecuritySpy and another competitors software on my Mac Mini Core 2 Duo with a single HikVision DS-2CD2032-I (w/ Firmware 5.2.0). The camera is wired and set to record in 1080p/30fps/30iframe.

    The competitor software records well and captures motion accurately. SecuritySpy has a lot of corrupt video with ghosting and artifacts, creating either misfired events when motion did not occur, or useless video when motion does occur. I then get error emails from the software saying "Error communicating with the network device "Front Porch" 3.4.2,10,835 Excessive packet loss from network device, the network may be too slow or defective, or this computer may be overloaded. Check the network and/or reduce this camera's frame rate." Why would SecuritySpy not be able to handle it, where the other software can? The network is fine, and I would hate to reduce the frame rate.
  • The video stream from the camera is made up of RTP packets - normally hundreds of these per frame. Fundamentally this problem is caused by some of these packets going missing on the way from the camera to SecuritySpy. This causes the corrupt video that you are describing.

    There are several possible causes, including a slow network or under-powered computer, hence the error message that SecuritySpy is generating. However a slow network doesn't appear to be the cause of your problem.

    There are two additional problems interacting here. One is the camera's fault: it is generating video data continuously, and will have a certain buffer size where this data sits after it is generated, waiting to be sent over the network. If the data is being consumed at a slower rate that it is being produced, then the buffer will become full, and the camera has a problem. What the camera should do in this situation is finish sending the current frame intact, and wait for more buffer space to become available before generating the next frame. This will reduce the frame rate a bit but will not cause any video corruption (most high-quality cameras, e.g. Axis, Sony, Vivotek etc. employ this method). However what your camera actually does in this situation is drop packets indiscriminately, leading to partial data for some frames, causing the corruption. I'm not saying your camera is low quality - Hikvision produce great hardware, but their cameras' firmware would be significantly improved by addressing this problem.

    On SecuritySpy's side, it appears to be consuming the data too slowly. One possibility is that the video is simply taking too long to decompress (decompression is required in order to display the video to the screen amongst other things). 1080p 30fps H.264 video is very high-spec, and it will put a lot of demand on the computer's CPU. The other software you are referring to may be using a different library to decompress the H.264 video, which may account for the difference; SecuritySpy uses QuickTime for this, which isn't the fastest, but it is very high quality.

    The other possibility on SecuritySpy's side is the performance of its network code. There is a balance to the struck here between computer resource usage and pure performance. In SecuritySpy we have designed the network code to run efficiency, using a low amount of CPU and memory, because there may be many cameras sharing these limited resources. However this does limit its performance.

    So, I have made some tweaks to SecuritySpy's network code in the latest beta version of SecuritySpy that significantly increase its network performance. Please test this and let us know if it resolves your issue.

    Finally, for general-purpose video surveillance, 30fps is excessive - we normally recommend 5-10fps. If you use a lower frame rate it will definitely help with your problem.
  • Ben... I have 4 HikVision cameras on my system. Its definitely an underpowered Core 2 Duo older Mac Mini... I see some of these same error messages from time to time on this system ( on second system with newer mac mini I never have issues like this ) so just for something to do I've installed this latest beta version on the slower mac mini... will watch this for a couple of days and see if the number of error messages I get is less. I am running at a frame rate of 10fps on my cameras. I'm curious to see if the network changes you made make a difference on my system. But two of my cameras are actually coming across a wifi connection as well. I'm curious to see how this plays out.
  • Running the latest beta now for a few days I've noticed a significant decrease in the errors in the log running on an underpowered system. So whatever network changes you put into the beta I hope they make it to the next release. It appears to me that the only time I have issues anymore is if more than one camera is recording to disk at the same time. Thats just a reflection of the system not being powerful enough to handle the total load requested of it. Sure wish Apple would update the mac mini, but this latest fix has retired the thought for now of getting a dedicated NVR or being forced to update the mini before the next updates from Apple. Thanks Ben !
  • Thanks for sharing your experiences doodah, I'll make sure the new network tweaks make it into the next full release version of SecuritySpy. For now, simply continue to use the beta version.

    It has been unusually long since the last update of the Mac mini line, hopefully Apple will release some new more powerful models soon. It makes a perfect server computer for SecuritySpy installations.

Howdy, Stranger!

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