Revision [5555]
This is an old revision of StreamCCTVRaspberryPi made by ZorrUno on 2020-05-12 03:04:48.
Quad CCTV display
Use of an old raspberry pi, plus a basic automotive 7" LCD screen to display streamed CCTV images.Requirement
Resolution was not that important - it was more about using cheap/minimal hardware to see activity, and bringing up another larger image on the main computer/TV if needed. The monitor I'm using is only 800x480, so this is fine as a visual display, but most of the the cameras I use are 4MPix (and they are recorded in 4MPix) with a configurable substream (usually D1 of CIF).Equipment
-- Raspberry Pi (V1), with ethernet and composite video output (less than $30 2nd hand)-- Composite male to male cable
-- 12V car monitor (I have 3 of these, picked up in a sale for $15 each)
similar to:
https://www.trademe.co.nz/motors/car-parts-accessories/rear-view-cameras/listing-2618879503.htm
-- Power supplies for Pi and monitor
Choice of players
I planned to use omxplayer as this mostly just works on the Pi using framebuffer (no gui or other x layers). Additionally there is a great python project called displaycameras that uses this to overlay multiple rtsp streams on screen, and can cycle though them and place them in quadrants like a CCTV DVR display etc.omxplayer needs hardware decoding and on first check the pi that I used can only software decode the H.265 streams from my cameras so I could not get the streams to decode at first. I did go back and manage to reconfigure my camera substreams to work on it eventually though (with some tweaks to camera settings), so have 2 methods working.
For reference, my cameras tout H.265, H.265+ and H.265AI modes (but not all for main and substream), and because these are pretty generic Chinese manufactured IP cameras, what these actually mean in terms of stream standards are unclear. Not all my cameras seem to have all these settings, even though they are similar cameras from the same supplier (and I've updated the firmware for all)
Method 1 - VLC
This is a simple way to get a single image running in full screen.I installed Raspbian full desktop, but set it to start without x running (set using raspi-config) and the pi user automatically logged in. VLC doesn't like running as root.
I appended this to /home/pi/.profile
(so it will start up when the pi user logs in... which is on startup now)
cvlc -f --aspect-ratio=16:9 "rtsp://192.168.1.123:554/user=blah&password=blah&channel=1&stream=1.sdp?Real_stream"
The -f switch is to display fullscreen, and using cvlc plays without any of the other VLC window overhead
The IP address is the camera, and port of the RTSP stream. Use the camera username and pass. Most cameras have differing strings for an RTSP URL so you need to check in your camera manual.
I had issues with larger streams, in that the stream would eventually drop out never to return. A camera stream in CIF with a decent number of i-frames seemed to work. Even a D1 stream seemed to be too much, but more playing may have solved it.
Method 2 - Displaycameras and omxplayer
Install raspian lite on the raspberry pi. I used 2020-02-13-raspian-buster-lite at the time.set up ssh, locale etc as needed, but not a lot of other changes needed from the default raspian minimal setup.
Follow the instructions in https://github.com/Anonymousdog/displaycameras and download/install the scripts.
The install adds all dependencies and queries you for other changes. For my early Pi V1 I set video split to 265MB GPU and overscan turned off.
I recommend you verify omxplayer will play your feed RTSP URLs first. To definitively rule out problems with omxplayer not playing RTSP feeds, run the following in an SSH session, or maybe even install and text on another machine first:
sudo omxplayer --no-keys --no-osd --avdict rtsp_transport:tcp <camera feed URL> --live -n -1 --timeout 30
For a basic quad display, with no changing of camera feeds on screen (you can rotate more feeds onto the display), this was the configuration after a fair bit of playing to get the layout balanced and the entire images on screen.
/etc/displaycameras/layout.conf.default
windows=(upper_left upper_right lower_left lower_right) window_positions=( "25 10 359 259" \ "360 10 700 259" \ "25 260 359 480" \ "360 260 700 480" \ ) camera_names=(Cam1 Cam2 Cam3 Cam4) camera_feeds=( \ "rtsp://192.168.1.121:554/user=blah&password=blah&channel=1&stream=1.sdp?Real_stream" \ "rtsp://192.168.1.122:554/user=blah&password=blah&channel=1&stream=1.sdp?Real_stream" \ "rtsp://192.168.1.123:554/user=blah&password=blah&channel=1&stream=1.sdp?Real_stream" \ "rtsp://192.168.1.124:554/user=blah&password=blah&channel=1&stream=1.sdp?Real_stream" \ )
You can also tweak settings in /etc/displaycameras/displaycameras.conf, I upped the timeouts and changed blank="true" to blank the terminal window nicely before displaying the feeds, but suspect the default timeouts will be fine.
restarting the service:
sudo systemctl restart displaycameras
Resources
Monitor draws around 400mA on 12V
On the Pi, omxplayer.bin uses between 8 and 12% CPU load for each instance (4 D1 streams in this case) and about 10% memory for each.
NotesOn the Pi, omxplayer.bin uses between 8 and 12% CPU load for each instance (4 D1 streams in this case) and about 10% memory for each.