this age of mass surveillance…
… who is observing “the observers”?
if the user wants to know who or what is lurking behind the house… the user needs to view live streams of surveillance cams on GNU Linux.
vlc player does the job nicely 🙂 and is available for most distros (thanks all involved!)
of course 99% of all surveillance cams sold are “Made in China” (often the same model is sold under different brands… the H.VIEW_HV-500G2 4K IP Kamera 8MP POE Surveillance cam (3840x2160P)cam is technically almost identical to the ANNKE and the more expensive HIKVISION)
forget about the onboard features… it can not do ftp upload, it is said it can do nfs uploads to a fixed ip address…
so unless some server is processing that pretty good picture quality (also at night)… it will probably be a pure “viewing via vlc player” device.
- resolution: 3840x2160P 8MP-4K
- Objektiv: 2,8mm
- 24x IR LED night vision lights: Yes /Microphone: Yes
- power-input: DC12V
- supports: Onvif, FTP, NAS, NFS, RTSP
- example MAC: F0:23:B9:57:1B:XX (Ieee Registration Authority)
- (which probably means: they did not bother to register for a MAC at all)
What those cams also have in common: most “build-in”/onboard features like “motion detection” might not work, so those cams can only be purely seen as “cams that can stream udp rtsp video and audio via network”, all the “motion detection” is probably best done by a central server software ( still have to find the perfect Open Source GNU Linux solution for that)
- have tested the h.view extensively
- + picture quality: is pretty good day and night
- except when: there is fog at night, the particles are illuminated by IR LEDs and the visibility goes to zero
- uses a Sony Complementary metal–oxide–semiconductor (CMOS) (has nothing to do with the BIOS CMOS) picture sensor
- + outdoor durable: the cam even survived some rain and snow storms and below 0 degrees
- + works with TPLink PoE adapter reliably
- + NTP time server sync works 🙂
- – https does not work only unencrypted login via browser possible
- – support for firefox seems pretty bad (the basic config can be done, but it seems the producer heavily relies on iexplore + flash)
- – FTP does not work, only NFS is said to work NFS (NFS is fast which is good, security wise both protocols are pretty bad)
- – does not come with SD Card installed per default
- – DNS server can not be changed (!? per default 188.8.131.52 (Google’s) and 184.108.40.206 (AliBaba Cloud, hostname: public2.alidns.com) is set)
- whois 220.127.116.11
- netname: ALISOFT
descr: Aliyun Computing Co., LTD
problem with mplayer: it does not seem to user hardware encoding in Debian 10, so it is skipping a lot of frames… so right now vlc is the only proper options to view those high definition streams (with reasonable (x<100%) cpu usage)
- connect with browser to cam
- check what ip is still free on the user’s network and asign a fixed ip to the cam (write it down)
- set password (leave default username for h.view and annke “admin”)
hostnamectl; # tested on Operating System: Debian GNU/Linux 10 (buster) Kernel: Linux 4.19.0-13-amd64 Architecture: x86-64 su - root; # become root apt update; apt install vlc; # install vlc player apt install mplayer; # install mplayer # the user will have to consult either # 1) the manual of the surveillance or webcam # 2) the web dashboard backend what the specific url of the rtsp stream is mplayer rtsp://username:firstname.lastname@example.org.XX:554/live/main # will output the stream in a smaller window (so multiple can fit into one screen) # will move output window to x:100 y:100 mplayer -noborder -x 640 -y 460 -geometry 100:100 mplayer rtsp://username:email@example.com.XXX:554/live/main
what software to use?
vlc does a great job at viewing rtsp streams.
in vlc when a stream like this works, the user can then go: Media -> Save Playlist to file.m3u and place that Playlist.m3u on the Desktop.
With a simple double-click that streaming can be started.
mplayer works nice too, but realized it was doing a lot of “lazy” painting, which basically means if the user looks carefully at the clock… it is sometimes not updating… meaning… the codec thinks no major change to the picture happened and thus does not update that part of the screen.
once a cat was walking across the scene and it seemed like the cat froze in place… but no… it was just frame video compression and skipping in action.
maybe this can be corrected with some setting tweaking.
ffplay consumes way too much (100%) cpu usage.
here are more screenshots from the web backend:
(GNU Linux Debian 10 + latest Firefox 84.0.2 (64-bit) was used)