zorruno wikki: Pi CCTV Monitor RTSP Display

Pi CCTV Monitor RTSP Display

Use of an old raspberry pi, plus a basic automotive 7" LCD screen to display streamed CCTV images.
Quad CCTV Display

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 these: Trademe, Jaycar, Aliexpress,
-- Power supplies for Pi and monitor

Choice of software 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 15% CPU load for each instance (4 D1 streams in this case) and about 10% memory for each.

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.
-- 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 use the text overlay as if the stream stops, it is helpful to have a clock to see if the stream has stopped or is delayed.
-- RTSP streams can be reaeeeallly delayed if they are large (eg a 4MPix stream). 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.
-- Be aware that dropping a stream down in resolution is resource intensive, so using a sub-stream or low quality/resolution stream is important.

Improvements

-- 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.
-- The monitor is a little annoying as it displays the input name (AV1) in the top right until you press the IR remote to select something. If I was more pedantic I'd try and automate this. Also, it draws 110mA on standby (remote on/off) so I will be switching power off when not used (2020-08-21 monitor is now on a 12V supply switched by the home automation system).

References

https://selfhostedhome.com/raspberry-pi-video-surveillance-monitor/
https://community.ui.com/questions/Tutorial-Raspberry-Pi-3-RTSP-Stream-Viewer/cc54f892-b8d6-46c5-81f3-ee58b9284889

Last edited by ZorrUno
Sun, 23 Aug 2020 22:49 UTC [diff]


--
CategoryLinux
CategoryCCTV
CategoryRaspberryPi
CategoryHomeAutomation
CategoryMicrocontrol
CategorySecurity