Matt's Notebook

My first sticky note is to remind myself the steps I've gone through to use some old Raspberry Pis as cameras so I can watch the cats when we're not at home.

What I've tried so far

• Purchased a Pi Camera Module 3 to play with.
• Installed Motion and MotionEye.
• I chose MotionEye because it lets you have multiple cameras in a single interface which I classified as a nice to have feature, but I don't remember a lot of the setup, I did this months ago, which is one of the reasons why I setup this page.
• I learned that libcamera is confusing and the new rpi camera module 3s are not super compatible. I can't get them to natively load into MotionEye via /dev/media# or /dev/video#
• It looks like I setup a system service to launch motioneye and it calls motion, but in a weird way.
  1. MotionEye service runs /usr/local/bin/meyectl startserver -c /etc/motioneye/motioneye.conf
  2. Inside motioneye.conf, I've set motion_binary /usr/local/bin/motion.sh which is a shell script that runs motion via /usr/bin/libcamerify /usr/bin/motion $@
• I don't remember why I did it this way, probably trying to find a way to get the rpi camera to work natively with motion.
• Learned that some libcamera packages were renamed rpicam in bookworm when I couldnt figure out how to install the test apps to verify functionality. :–|
• Followed this forum post which is says MediaMTX is compatible with the camera module 3s, and you can broadcast the video on RTSP into MotionEye. (This is not super ideal but will work for testing)
  1. Enable '8: RPi Camera' at DietPi-Config/Display Options/
  2. In /boot/config.txt: set camera_auto_detect=1 and comment out start_x=1
• Downloaded MediaMTX
  1. The premade binary crashes, expecting libcamera0 not libcamera, I tried flipping my install but libcamera0 uninstalls libcamera-tools and libcamerify which I need for motion.
  2. Next, I tried to compile directly, based on this comment but ran into issues with libcamera-dev, even though I had it installed, MediaMTX could not find the C files. I suspect it's something to do with the distinction between libcamera0 and libcamera, but I didn't investigate this any further.
  3. Instead, I linked ln -s libcamera-base.so.0.2 libcamera-base.so.0.0 and ln -s libcamera.so.0.2 libcamera.so.0.0 in /lib/arm-linux-gnueabihf/ on the suggestion of this post so that the premade binary would run. I don't feel great about random linking things in /lib I don't know if this will break package management in the future, but we'll see.
• Setup MediaMTX with rpiCamera as the source.
  • paths: stream: source: rpiCamera
  • This is insecure, and will need to be locked down before leaving this running as a service long term, even though it's in my local environment. I'll setup auth or lock it down to localhost.
• Loaded the Camera into MediaMTX rtsp://localhost:8554/stream UDP
• Success? Kinda. I can see the camera in MotionEye for the first time.

Conclusion

It is extremely slow. I assume because its being broadcast via RTSP and then also being broadcast via MotionEye. Motion is also throwing OOM errors into dmesg. These are both probably because the pi is underpowered for what I'm trying to get it to do. Story of my life, playing around with Raspberry Pis :-D

Next steps

1. I will re-investigate my choices regarding motion. If I am using RTSP do I need to run libcamerify with motion?
2. I will see if running the RTSP stream alone is faster than rerouting it through MotionEye – I suspect it would be.
3. I will look for some simpler remote video solutions as a proof of concept before trying to setup the full MotionEye system, and see if other things natively support the camera module.
4. I could also try run MotionEye on a standalone pi as a server, maybe a Pi 2 that doesn't have wifi, and run my cameras on my pi3s and connect them all as remote cameras.

That's all for now.

@[email protected]

#rpi #rpicamera