Quad CCTV display

Using a 7 inch car monitor to display multiple Streamed CCTV images

Requirement

Use of an old raspberry pi, plus a basic vehicle 7" LCD screen to display streamed CCTV in an office.

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).

Also, there is a great python project called displaycameras that uses this to overlay multiple rtsp streams on the pi, and can cycle though them and place them in quadrants like a CCTV DVR display etc. https://github.com/Anonymousdog/displaycameras

Unfortunately, omxplayer needs hardware decoding and the pis that I used can only software decode the H.265 streams from my cameras. I did go back and manage to reconfigure my camera substreams to work on it eventually though, so have 2 methods working.

Method 1 - VLC

Installed Raspbian full desktop, but start without x running (set using raspi-config) and the pi used logged in. VLC doesn't like running as root.

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 seems to be too much.

Method 2 - Displaycameras and omxplayer

Verify omxplayer will play your feed RTSP URLs first
To definitively rule out problems with omxplayer not playing your RTSP feeds, run the following in an SSH session:

sudo omxplayer --no-keys --no-osd --avdict rtsp_transport:tcp <camera feed URL> --live -n -1 --timeout 30

Follow the instructions in https://github.com/Anonymousdog/displaycameras

I still have the full raspbian gui installed, (it boots up without it though) and expect that I don't need any packages from it now so will re-install the minimal version at some stage.

My basic quad display, with no changing of camera feeds on screen (you can rotate more feeds onto the display)
/etc/displaycameras/layout.conf.default

windows=(upper_left upper_right lower_left lower_right)
#these could probably be tweaked or cropped a bit
window_positions=(
"0 0 399 239" \
"400 0 799 239" \
"0 240 399 479" \
"400 240 799 479" \
)
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, but I didn't need to change the defaults.

restarting the service:

sudo systemctl restart displaycameras

Improvements & Notes

-- A 3rd method would be to use the motion project https://motion-project.github.io/ as it supports rtsp streams- this would have the added advantage of doing some motion detection directly to alert if something is going on (on screen or with sound). This obviously would require some processing power - not sure if the V1 of the Pi would be suitable for more than one camera.
-- With the VLC method, If the stream drops (eg camera reboots) it isn't picked up again by VLC. The script should probably check that, or just restart the stream say every hour. Displaycameras is much more reliable at maintaining the stream properly.
-- Make the OS install as minimal as possible
-- I could use some of the wasted hardware from the pi to do some switching of displays (a button to bring up one of the inputs full screen? PIR to turn off/blank the screen if no-one is watching?
-- I could potentially find a micro board even more minimal that would run this, if it had composite output (and if it would reduce power use)
-- I could potentially use a raspberry pi cam or usb camera on the pi to display a feed locally? Not sure what... maybe the office door.
-- The screens also have a second composite input, and a trigger wire (designed for a reversing camera) so this could be used to switch displays... but probably easier to do in software.
-- I'd be interested to see if I can make one of my streams portrait, as it lends itself to that (and have two landscape, one portrait images on the monitor)
-- I'm not using any audio and the monitors do have speakers, but I just plan to just feed this back into my desk audio mixer from the Pi with other desk audio (computers/TV) so I can ramp cctv sound up/down as needed.
-- RTSP streams can be reaeeeallly delayed if they are large. I had one on my computer that confused me as I was watching 20 minute old footage thinking it was live. Check your clock display occasionally to be sure this isn't an issue.

Sorting by

Revision [5533]