motioneye-project
Cannot add ov5647 CSI camera - unable to open video device
I'm running a Raspberry Pi 4B rev 1.5 with raspbian 12.11 bookworm
$ uname -a
Linux eyes 6.12.25+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.25-1+rpt1 (2025-04-30) aarch64 GNU/Linux
I've got an ov5647 camera connected to the CSI0 port (the one between hdmi1 and AUX).
I installed motioneye via the guide on the main repo page - installation went through w/o any problems. motionEye Version 0.43.1b4 Motion Version 4.7.0
libcamera seems to detect the camera:
$ libcamera-hello --list-cameras
Available cameras
-----------------
0 : ov5647 [2592x1944 10-bit GBRG] (/base/soc/i2c0mux/i2c@1/ov5647@36)
Modes: 'SGBRG10_CSI2P' : 640x480 [58.92 fps - (16, 0)/2560x1920 crop]
1296x972 [46.34 fps - (0, 0)/2592x1944 crop]
1920x1080 [32.81 fps - (348, 434)/1928x1080 crop]
2592x1944 [15.63 fps - (0, 0)/2592x1944 crop]
But vcgencmd doesn't
$ vcgencmd get_camera
supported=0 detected=0, libcamera interfaces=0
v4l
$ v4l2-ctl --list-devices
bcm2835-codec-decode (platform:bcm2835-codec):
/dev/video10
/dev/video11
/dev/video12
/dev/video18
/dev/video31
bcm2835-isp (platform:bcm2835-isp):
/dev/video13
/dev/video14
/dev/video15
/dev/video16
/dev/video20
/dev/video21
/dev/video22
/dev/video23
/dev/media1
/dev/media3
unicam (platform:fe801000.csi):
/dev/video0
/dev/media2
rpi-hevc-dec (platform:rpi-hevc-dec):
/dev/video19
/dev/media0
bcm2835-codec (vchiq:bcm2835-codec):
/dev/media4
The camera has to be connected properly, because when I run libcamera-hello, I get a preview window with a live preview showing what's in front of the camera! I'm not showing an image, but here's the output of the program:
$ libcamera-hello
[0:17:49.881334985] [2072] INFO Camera camera_manager.cpp:326 libcamera v0.5.1+100-e53bdf1f
[0:17:49.929750802] [2075] WARN RPiSdn sdn.cpp:40 Using legacy SDN tuning - please consider moving SDN inside rpi.denoise
[0:17:49.932465684] [2075] INFO RPI vc4.cpp:440 Registered camera /base/soc/i2c0mux/i2c@1/ov5647@36 to Unicam device /dev/media2 and ISP device /dev/media1
[0:17:49.932634915] [2075] INFO RPI pipeline_base.cpp:1107 Using configuration file '/usr/share/libcamera/pipeline/rpi/vc4/rpi_apps.yaml'
Made X/EGL preview window
Mode selection for 1296:972:12:P
SGBRG10_CSI2P,640x480/0 - Score: 3296
SGBRG10_CSI2P,1296x972/0 - Score: 1000
SGBRG10_CSI2P,1920x1080/0 - Score: 1349.67
SGBRG10_CSI2P,2592x1944/0 - Score: 1567
Stream configuration adjusted
[0:17:50.001828744] [2072] INFO Camera camera.cpp:1205 configuring streams: (0) 1296x972-YUV420/sYCC (1) 1296x972-SGBRG10_CSI2P/RAW
[0:17:50.002318809] [2075] INFO RPI vc4.cpp:615 Sensor: /base/soc/i2c0mux/i2c@1/ov5647@36 - Selected sensor format: 1296x972-SGBRG10_1X10 - Selected unicam format: 1296x972-pGAA
No matter which camera I add on the motioneye UI, I get a gray image displaying unable to open video device
The first ones I've tried are the "unicam" models, because their devices /dev/video0 and /dev/media2 match the output of libcamera-hello, where I get an actual preview image. But no success.
Is there any way to see a (debug) log that shows why motioneye isn't able to open the devices? Permissions?
This fixed my problem, technically: https://github.com/motioneye-project/motioneye/issues/2812#issuecomment-1817391735
Changing /etc/systemd/system/motioneye.service
from
...
ExecStart=/usr/local/bin/meyectl startserver -c /etc/motioneye/motioneye.conf
...
to
...
ExecStart=/usr/bin/libcamerify /usr/local/bin/meyectl startserver -c /etc/motioneye/motioneye.conf
...
Suddenly ME listed the camera's device path (/base/soc/i2c0mux/...) in the drop down menu to add a new camera and I can now see an image in ME.
However, now I cannot change the resolution of the camera, it's stuck to 320x200 and changing the resolution in the UI just crops the image weirdly.
If you have the option to "Enable legacy camera" in raspi-config (in the interfaces section), turn that on. As far as I'm aware, motioneye still doesn't support libcamera.
If you have the option to "Enable legacy camera" in raspi-config (in the interfaces section), turn that on. As far as I'm aware, motioneye still doesn't support libcamera.
I knew about that option, but it seems to have been removed in raspbian bookworm, I do not have it any more in raspi-config.
I reverted back to bullseye.
The MMAL library has been removed from RPi OS Bookworm in the meantime. See above usage of libcamerify, which provides a common V4L2 API on top of libcamera. The full steps:
apt install -y libcamera-v4l2 libcamera-tools
sed -i 's|/usr/local/bin/meyectl|/usr/bin/libcamerify /usr/local/bin/meyectl|' /etc/systemd/system/motioneye.service
systemctl daemon-reload
systemctl restart motioneye
Yes and I got it working that way, like I wrote. But it only worked partially, because I wasn’t able to change any of the camera’s parameters, like with MMAL.
I like the consequent move towards libcamera on the OS end. Question is: Are there any plans in motioneye to adopt/migrate all the features that worked with MMAL? It seems to me this hole libcamerify approach, probably using ld_preload “hacks, is only meant for a transition phase?!
The problem is that motion itself does not support libcamera, so there is currently no way for motionEye to support it directly either. libcamerify is part of the libcamera project itself, at least, but of course it is not perfect.
Not sure whether the resolution limitation is an issue with libcamerify, or something we can fix in motionEye, or a limitation with certain camera module models in combination with libcamerify. Needs some testing, I guess. Should be possible to use enter a subshell:
libcamerify bash
And then check which info and resolutions v4l2-ctl gives for the resulting /dev/video* device(s). Might be something to report at the RPi fork of the libcamera project: https://github.com/raspberrypi/libcamera/issues
motion v5 supports libcamera natively iirc, im not sure how stable it is atm. if motioneye intends to play nice with current hardware and software then utilizing motion v5 should be looked into
Great news. There is no release (or pre-release) tag for v5 yet, but I guess can be tested with an own build. We'd still need to find a way to detect libcamera cameras correctly, i.e. to not show their dozen's of /dev/video* nodes, but a single node instead. libcamera tools and again a special handling/camera type that replaces MMAL looks like the most probable way. I wished they would behave like regular V4L2 cameras, so the we could remove all this annoying special-handling 🙄.