Managing and using ONVIF IP cameras with Linux
people.skolelinux.org
people.skolelinux.org
Some alternatives are starting to appear, but this is an industry that moves really slow. Things only seem to happen when a new player disrupts the market and starts taking market share, as AXIS did with cheap IP cameras back in the day.
The most important part is getting the video. The popular open standard is RTSP. Many cameras have astonishingly poor RTSP implementations. See https://github.com/scottlamb/moonfire-nvr/wiki/Cameras:-Reol... for some of what I'm talking about. That ONVIF page (https://www.onvif.org/conformant-products/) says everything is fine for several Reolink models, but I don't believe it!
After that would be some way to get the analytics, assuming the camera has them and they're any good. If the ONVIF API works well, great, but a proprietary API isn't that bad IMHO as long as it's simple.
My opinion differs a little bit. If I buy a PTZ I know some here think those are a waste I expect to be able to control it from an open source application. If I can control all aspects of PTZ audio and video then that is good enough for me, but may not be good enough for others.
If I could find a brand that actually did regular maintenance and wasn't a walled garden (such as Ubiquity), I would replace all of my camera's.
Security comes from networking tricks (VLAN's, etc), which is far from ideal.
Not pretty, not reliable, but surely more secure. Though the best thing is to air-gap or at the least firewall.
I wouldn’t discount network tricks, tho. A non-routed vlan for cameras to talk to the nvr and all video access through the nvr only keeps cameras pretty safe. Much easier to secure one nvr than 100 cameras
There's some various other boards we could possibly use. Few are small. Many lack CSI interfaces for attaching cameras. And then, for your outdoor use, ruggedizing is another huge leap.
Alas though, you'll still be stuck with a device that only lasts 3 years before it's insecure. I'm in the minority, but personally I'd rather a more open ended & flexible system like Linux, with more small-pieces-loosely-coupled possibilities in front of me, where-as with Android I'm going to have 2 or 3 different apps with pretty fixed/limited capabilities that I'll never be able to improve or adjust.
In some ways, the web is kind of the possible remedy here. If the phone runs a webpage that accesses the camera & webrtc & does the things, that'd kind of be ideal, because it's insta-deployable to any vaguely general-purpose hardware. Developing the webrtc chops though to be able to make use of this well though, that's a totally separate conversation.
You'd still have binary blobs of HAL for some peripherals but that's not different from raspberry pi.
They seem to all use the same generic/white label Chinese firmware with barely anything changed about it. Their advertisements of "up to X viewers" really only ever means max of 1 or maybe 2 if you want a decent/max resolution or framerate.
The devices and their video streams are often quite unstable (needing a daily reboot or restart of the stream), jittery and not smooth.
The cost of the device does not seem to make a difference either, whether it's a $50 device or $300+.
Anyone have recommendations or tips on either better brands or maybe some idea of what I might possibly be doing wrong?
I want the quality and cheapness and reliability of wyze with onvif.
I haven't tried a lot of wifi cameras, but I'm not surprised you're having trouble, particularly with multiple simultaneous streams talking directly to the camera.
* Wired should be much more successful. To be clear, wired cameras still have crap firmware [1] but you should be able to get a stable stream.
* If the camera must be wireless, try using an RTSP proxy server so that there's only one direct client. The proxy server can multiplex so you can have several things connecting to it, and ideally they go over the wired LAN. Even if they don't, the wifi hardware/software on anything that isn't a cheap camera is probably a lot more stable. Also, the RTSP implementation is probably a lot better at handling mixed network conditions. I've noticed several cameras' RTSP/TCP support (aka RTP over RTSP interleaved channels) will truncate RTSP data messages when the TCP send buffer fills, throwing off the framing. Nothing good happens after that. And UDP has its own problems (single lost packet => seconds of video questionable/useless, but still sent, and there's no real congestion handling unless they've done a miracle in application code with infrequent RTCP reports). Edit: also, some cameras have a particular bug [2] in which they will continue sending RTP-over-TCP data to a file descriptor after it's closed. The file descriptor is often reused while this is still happening, which causes all sorts of problems, not the least being sending sensitive data over an unauthenticated channel.
[1] In particular, I have very low expectations for their security. Poor software quality, backdoors. Firewall them so nothing can connect to them other than your proxy server / NVR and so that they can't connect out either.
On the NVR side, I'm slowly working on it, including https://github.com/scottlamb/moonfire-nvr and https://github.com/scottlamb/retina . Help welcome!
https://medium.com/@monoclechris/raspberry-pi-onvif-cctv-cam...
* The sensor isn't that good to begin with. Too small.
* The SoC is iirc end-of-lifed by the manufacturer and limited in terms of H.264 encoding (low-res/low-fps), even with good drivers, which it doesn't have (yet?). No NPU for on-camera ML-based analytics.
* No real-time clock (although you could add one via I2C).
* I don't think they've gotten the community interest they were hoping for, probably in part because of the problems above (and, circularly, this is part of why the driver situation is not good).
* This is a dev board. It's not ruggedized. And given the above, I don't think a productionized version will happen.
I think you can get closer with a Pi Zero 2 W and HQ camera module, but I don't have any suggestions for ruggedization, autofocus, or toggling an IR cut filter, which are must-have properties for most applications.
For the two way voice chat, alarm and in some cases flood light and pan/zoom controls there is no substitute at all.
https://partofthething.com/thoughts/controlling-a-amcrest-pt...
So far the "least worst" of the low cost IP cameras I have tried have been TPLINK TAPO.. once they are configured for onvif and IP set by tying to mac address, they can be blocked from the internet access at the firewall and work fine standalone. The only non-TPLINK app I have found that can work with the PTZ mode of the TAPO C210 is the proprietry ONVIER android app.
ZM has been alive and actively maintained for nearly twice as long as Hasio..
- wired Ethernet (POE is nicer)
- no WiFi nor Zig
- speaks ONVIF
- ruggedized
- 4K
- powerful infrared LEDs
Cannot believe one does not exist.
Not quite at the "TAKE MY MONEY" point yet.
1. manufacturers don't actively support genocide (rules out anything involving Dahua, Hikvision, Huawei, as IPVM has described extensively), are allowed in the US (look up the Secure Equipment Act of 2021)
2. has a nice large sensor (the 1/1.8" models are great, but see point 1)
3. supports open source firmware (none of them do AFAIK)
4. reasonably affordable (surprisingly, this part is not the biggest problem)
5. nice-to-have: has an NPU for on-camera analytics (there are cameras with this but mostly from the genocidal manufacturers...)
The best I've got is GeoVision. No open-source firmware, sensors aren't as large as I'd like, no NPU, but relatively decent otherwise. https://github.com/scottlamb/moonfire-nvr/wiki/Cameras:-Geov...
edit: actually, some of these 6MP Hanwha cameras look promising. Several say they have 1/1.8" sensors. Not cheap though, and no eyeball/turret form factor.
- VLAN support
- MAC-layer encryption (802.1x)
- FOSS software
- Common Criteria compliant (logs remote accesses)
- TPM v2 (Linux Trouser)
- No remote firmware capability
How hard could it be?