Xiongmai based IP Cameras & Security Spy
Hi,
I have tried running a couple of walled-off Xiongmai OEM IP cameras in my local network. Similar to this one, for example: https://www.aliexpress.com/item/1005002808557603.html
All of them have the same problem: initially, Security Spy will display a clear stream via the ONVIF profile. At an unpredictable point the stream will become garbled, in many different ways. With some it´s blocky colored artifact-rows, with others it´s mostly a grey image with a couple of coloured vertical stripes one will see. Sometimes the stream will recover by itself, sometimes not. This goes for H.264 and H.265 streaming XM cameras. I have tried to play around with advanced settings in Security Spy - to no avail.
Then I deployed the infamous XMEYE software "VMS" for Mac (Yes, I run Little Snitch and have blocked all phone-home domains of XMEYE in the router - you can not not run XMEYE Mac otherwise - or you shouldn´t.) Turns out the stream is stable and clear. I noticed that XMEYE installer drops a couple of libraries on the Mac that seem to correspond with H.265 and 264. But I just get that from looking at the file names of the files that XMEYE installer places on the Mac.
If Security Spy relies on MacOS video decoding and, say, XMEYE does so, too - why has the one a garbled stream and the other a clear one? Sufficient to note that these cameras work all well on Windows and Linux. I was unable to connect to these cams using VLC, so I don´t know whether it´s a MacOS problem or Security Spy specific one.
Anybody here in the forum who got XM cameras working with Security Spy? It would be a pretty good enhancement of Security Spy, as XM cams are really low cost, some of which still featuring very good low cost assembly quality, especially some PTZ ones. XM cams make up for most of the aliexpress IP cam stock, for example. When securely fenced off from phoning home, they could be used as low cost Security Spy connected cameras in areas that are vandalism prone and were cams get simply removed or smashed, for example.
Thanks for your thoughts.
Comments
-
SecuritySpy uses the macOS "VideoToolbox" framework for video decoding, which offers good compatibility and hardware-accelerated performance. But it's possible that the XMEYE software doesn't. Instead, it could use its own libraries for video decoding, or some standard library such as libavcodec, which is what VLC uses.
One thing that we have seen is some cameras alter their stream encoding parameters at regular intervals while streaming - these parameters are required for correct decoding of the stream. To check whether this is in fact the problem here, go to Preferences > Cameras > Device > Advanced Device Settings in SecuritySpy, and turn ON the option "Detect and adjust for video stream format changes". Does this resolve the issue?
-
No, it doesn´t, the stream still scrambles out. I have the impression it does it specifically when there is a lot of motion ongoing. But not always, it also scrambles at night, with rather still images with a lot relatively "solid" black.
-
I have a relating question: I noticed that SecSpy does not stop recording when the screen goes to sleep. While, for example, that horrible XMEYE VMS software does. It disconnects the camera and doesn´t record a thing when the screen is asleep. Is that down to VideoToolbox vs other libraries?
-
One more thing you can try in SecuritySpy is to try the "RTSP UDP" format option under Preferences > Cameras > Device. Some cameras just work better over UDP rather than TCP.
As for the screen sleeping issue with the XMEYE software - this won't be down to what particular decoder is in use, this could be something like App Nap (the suspension of apps by the system) or some other issue that SecuritySpy can cope with but the other software cannot.
-
Here is an update on details:
When I set the advanced option "Detect and adjust for video stream format changes", SecSpy will display the live window mostly ok, although, sometimes, there will be the odd breakdown on the picture into blocks and artifacts. However, when I close the live view window with all cameras in it because I want to lower energy consumption of my Mac when it runs headless, the scrambling returns in the recorded video. That was the recording without re-encoding by SecSpy.
When I do the same but set SecSpy to re-encode the video stream, the recorded video stream will be ok only if I leave the live window open. When I close the live window and leave it running like that, for many hours, there will be no recorded video at all for this camera. Looks like SecSpy simply doesn´t encode and write out recordings when the scrambling or format change occurs.
So by the looks, only a very energy intense work around seems to work for Xiongmai cams: that is setting "Detect and adjust for video stream format changes" in the advanced settings and set it to re-encode and leave the live window open and the screen active (I am using a DVI dongle that seems to keep the screen alive). For pure live monitoring that would be ok. But for remote headless recording it´s not. Is there any way to address this? Closing the live window will lower CPU impact by around a third, the MacMini goes noteably down in noise, with slower fan speeds and drops to lower energy consumption when I close the live window. Lower CPU impact translates into more cameras that I can set to higher quality.
Thanks.
-
PS: Yes, I tried the UDP setting very early on when this problem appeared, years ago. The switch between TCP and UDP will initially kind of kick start the stream but soon it will scramble again.
