Pi camera not functional on Bullseye

[Mr-Dave]

---

02/20/2023 Edit: Since this issue continues to get views years after the original posting, I'm adding a header to this issue. TLDR: Use libcamerify motion for the Motion application as documented here or the MotionPlus application.

---

0. Reviewed guide and contributing documents? (Yes/No): yep
1. version [x.y.z, hash, other]: pi bulleye
2. installed as a package or compiled from sources [deb, rpm, git, other]: source
3. standalone or part of third party [motion, MotionEyeOS, other]: standalone
4. video stream source [V4L (card or USB), net cam (mjpeg, rtsp, other), mmal]: v4l2/mmal
5. hardware [x86, ARM, other]: arm
6. operating system [16.04, Stretch, etc, FreeBSD, other]: bullseye

MMAL and V4L2 processing for the Pi Camera was converted to libcamera in the Bullseye version of Raspberry Pi OS. As a result of this change, the Pi camera is no longer functional in Motion.

EDIT: For those that wish to assist, we need a C routine to convert from one of the new Bayer formats libcamera is providing for the PI camera into RGB24.
Users wishing to use the Pi camera and Motion should continue with the Buster version of Raspberry Pi OS.

[tosiara]

I noticed that motioneye has instructions to use pi_buster 4.3.2 build on bullseye:
https://github.com/ccrisan/motioneye/wiki/Install-on-Raspbian-Bullseye
@ccrisan can you confirm that Pi camera really works on Bullseye? Have you tried the latest 4.4 version?

[Mr-Dave]

I'd add that the camera does not even function using ffmpeg directly. So using the v4l2 via netcam_url is not an option either.

[Mr-Dave]

A workaround has been found for this by disabling libcamera entirely and reverting to the previous camera stack as described in this link

Essentially it is:

Edit /boot/config.txt, remove the line "camera_auto_detect=1", and add "start_x=1" and "gpu_mem=128".

I would also note that to get my Pi zero camera to work I had to change the memory option from 128 to 256. So other users may also need to make this adjustment.

[Waltertscott10]

A workaround has been found for this by disabling libcamera entirely and reverting to the previous camera stack as described in this link

Essentially it is:

Edit /boot/config.txt, remove the line "camera_auto_detect=1", and add "start_x=1" and "gpu_mem=128".

I would also note that to get my Pi zero camera to work I had to change the memory option from 128 to 256. So other users may also need to make this adjustment.

Took me a week to figure this out, as described by Mr-Dave,
I now have motioneye running on Pi4 8G, however i have used "gpu_mem=256" successfully.
Pehaps this could be added to the install instructions for Bullseye?
Inportant note: /boot/config.txt needs to updated before commencing installation.

[brianolson]

Notes about deprecating the old camera api for libcamera
https://www.raspberrypi.com/documentation/accessories/camera.html

No promises, but I may take a crack at writing support for libcamera in the next few days.

[Mr-Dave]

Couple of things to keep in mind:

1. Motion will not be changing to C++. The C++ conversion is the realm of the MotionPlus application. I mention this because from what I have read, libcamera only has a C++ interface and nothing for C.
2. The libcamera interface via V4L2 did not seem to be stable. On my PI it was reporting different variations of the exotic Bayer format between reboots. Perhaps this may stabilize once libcamera matures to the point of being worthy of a release number. (The current version is v0.0.0+3310-4b24b0bf)
3. When I did revise Motion to use the Bayer format provided and send the images through the color conversion functions, the results were "poor". I am not sure if it was poor quality to start with coming out of the V4L2, poor conversion from Bayer to RGB or poor conversion from RGB to YUV.

[brianolson]

1. Ugh, yup. <libcamera/camera.h> and friends are all C++

For fitting into motion I imagine the replacement for mmalcam.c would have to be libcamera.cpp, but it could still export only extern "C" function signatures for the rest of motion to link to. Probably anyone with a C compiler has the associated C++ compiler, so I wouldn't feel bad about having libcamera.cpp in the build and expecting a C++ compiler, though 99% of the might be hidden inside #ifdef HAVE_LIBCAMERA

Also, the libcamera-apps repo has a new generation of all the command line option parsing stuff people expected from raspistill that was copied into motion/src/raspicam/. That's all C++. Dunno how annoying it would be to try to link that in. The source of the new main() function for libcamera-still isn't bad if you don't care about all the stuff linked in behind it. Instead of 'vendoring' source from libcamera-apps, maybe look for a subdirectory libcamera-apps/ that would be the git checkout of that source and refer to it directly. Autoconf that up as --with-libcamera-apps-src ?

But first, getting something working...

[Mr-Dave]

I want to make sure I'm clear on this so there are no surprises. The next maintainer of Motion can make a different decision but for me, I'm not pulling into the Motion application C++. If it is C++ it goes into the MotionPlus application.

[brianolson]

Oh, I get it now. I hadn't seen motionplus before. Maybe this issue of "add libcamera support" moves over to motionplus and becomes a "WONT FIX" over here?

[Mr-Dave]

The solution for Motion will be to use the video_device aka v4l2 or netcam_url. Neither of those options work right now.

The v4l2 can be hacked into Motion quickly by changing V4L2_PIX_FMT_SGBRG8 over to V4L2_PIX_FMT_SRGGB8 in the video_v4l2.c module. But it also requires cranking up the exposure and gain to almost the maximum and the resulting picture quality is very poor. This is probably the first time that the vid_bayer2rgb24 function has been used so I'm not sure if it is doing the color conversions correctly.

The other possible option to "fix" on the Motion side is the netcam_url option. This is essentially trying to figure out whether and with what options will the camera work using ffmpeg.

IMHO, the real issue seems to be upstream with the interface between the Pi camera and v4l2. If they had just implemented more mainstream pixel formats rather than picking the first one alphabetically, there wouldn't be an issue. The Bayer format seems to date back to the time of 5 1/4 floppies.

[richbl]

@Mr-Dave, thanks for summarizing the technical details here. I spent much of yesterday sorting through a PI setup on Bullseye and I was doing some serious Google-Fu to unwind what I was seeing. So...

What's your recommendation in the short-term for getting a RPI camera up and running under Motion? Is MotionPlus stable enough (very happy to see this getting spun up in C++). Or should we be falling back from Bullseye to Buster? I should add that I only really care about image detect/capture (for my use cases, video capture is less interesting).

BTW, been using Motion in various projects for many years (https://github.com/richbl/go-distributed-motion-s3), and digging it.

[Mr-Dave]

When I checked last, the option to revert to legacy camera stack was added into raspi-config so I'd recommend that approach.

[richbl]

When I checked last, the option to revert to legacy camera stack was added into raspi-config so I'd recommend that approach.

Confirmed. While a clean install of Bullseye (image as of this morning) doesn't offer the option for a legacy install of the PI camera stack in the raspi-config tool , after updating raspi-config itself to version 20220112, the option is then made available.

[TheRaven500]

I use two MMAL cameras (wavesahare) with motion 4.4.0 on bullseye. One on a Pi Zero2W and the other on a Pi 3A+. Both are working fine so far. Only one thing: There is a lag when motion is triggered. It lost 2-3s of video.
Edit: Ok, i think i found "why" it works. Looks like i am on the legacy camera stack (ERROR: the system appears to be configured for the legacy camera stack).

[wheimbigner]

It sounds like this should be marked as wont-fix, as we can reasonably assume no one is rewriting libcamera into C.

The bottom line is there are two camera interfaces for a Raspberry Pi: One that's deprecated by Raspberry Pi foundation, the other requires libraries that motion won't use for the foreseeable future.

There are two workarounds I can see. One is to use raspi-config to reenable the deprecated camera interface. The main drawback I've found with this is that it doesn't quite support some of the modes that should be supported at the correct framerate (I can get 1926 x 972 @ 30FPS on libcamera with the camera I'm using, but on legacy camera, I'm capped to 960x720 if I want 30FPS).

The other option - until such time as motionplus gets libcamera support, is to convert the camera interface into something Motion can use::

libcamera-vid --width 1296 --height 972 -t 0 --listen -o tcp://127.0.0.1:8888 --codec mjpeg

and then in motion.conf,
netcam_url mjpeg://127.0.0.1:8888

This allows you to use standard Raspberry Pi new-interface tools to open up an mjpeg stream, and then have motion connect to that mjpeg stream.

When I tested this latter option, I ran into some issues with this particular setup (like libcamera crashing when the stream got a bad connection, or like 200% CPU usage), though other conceptually similar setups probably exist (having libcamera write to a socket and have motion read from it or something).

[Mr-Dave]

I would disagree and invite you to re-read the comments in this issue. Motion supports use of ffmpeg and v4l2 devices. Once libcamera matures to level of having an actual release or version number, perhaps at that time it will have resolved all the issues and errors that currently prevent the use of these mainstream methods.

[kbingham]

Having just been pointed at this issue, I'd like to clarify a few points:

• EDIT: For those that wish to assist, we need a C routine to convert from one of the new Bayer formats libcamera is providing for the PI camera into RGB24.

libcamera provides the format you request. What you are seeing is the raw format from the sensor. You should not convert this manually in software, the HW ISP is supposed to deal with that, ... and that is the job that libcamera performs for you.

I'd add that the camera does not even function using ffmpeg directly. So using the v4l2 via netcam_url is not an option either.

As far as I am aware, no one has added libcamera support to ffmpeg, no. Gstreamer support is being worked on, but doesn't have enough people working on it.

Motion will not be changing to C++. The C++ conversion is the realm of the MotionPlus application. I mention this because from what I have read, libcamera only has a C++ interface and nothing for C.

Yes, libcamera is written in C++, C bindings could be written if someone requires it and is willing to work on or sponsor the work. Otherwise, the gstreamer API is C. Rust/Python/Go/Every other language binding would be nice to haves too.

The libcamera interface via V4L2 did not seem to be stable. On my PI it was reporting different variations of the exotic Bayer format between reboots. Perhaps this may stabilize once libcamera matures to the point of being worthy of a release number. (The current version is v0.0.0+3310-4b24b0bf)

Sounds like you are trying to access the V4L2 devices that represent the raw sensor. If you access this device, you need to get the frames from the sensor, and run them through the ISP, and manage all algorithms for auto-exposure/white balance etc. ... which is why we have written libcamera to do that part for you.

When I did revise Motion to use the Bayer format provided and send the images through the color conversion functions, the results were "poor". I am not sure if it was poor quality to start with coming out of the V4L2, poor conversion from Bayer to RGB or poor conversion from RGB to YUV.

Your conversion from Bayer to RGB/YUV was probably fine, but you would not have been running any auto-exposure or white balance or any other image enhancement that would be required to run through the ISP.

The v4l2 can be hacked into Motion quickly by changing V4L2_PIX_FMT_SGBRG8 over to V4L2_PIX_FMT_SRGGB8 in the video_v4l2.c module. But it also requires cranking up the exposure and gain to almost the maximum and the resulting picture quality is very poor. This is probably the first time that the vid_bayer2rgb24 function has been used so I'm not sure if it is doing the color conversions correctly.

Definitely don't do this ... it won't work ... as above.
We /do/ provide a V4L2 compatibility layer you can try. It's an LD_Preload and will make a libcamera device look like a V4L2 device so you can use your existing API ...

IMHO, the real issue seems to be upstream with the interface between the Pi camera and v4l2. If they had just implemented more mainstream pixel formats rather than picking the first one alphabetically, there wouldn't be an issue. The Bayer format seems to date back to the time of 5 1/4 floppies.

... I'm not sure how to comment there. There's no 'picking the first alphabetical format' going on. The bayer format is the real format produced by the sensor. You need to use the ISP to convert it to something you desire.

The Pi is using standard V4L2 interfaces, but the issues are that cameras are /complex/ ... to support the ISP, and different hardware, it's not possible to use a single V4L2 device interface. libcamera's goal is to manage as much of that for you so that you don't have to manage the ISP for every non-UVC camera. Up until now, all of this processing was handled by the GPU in a closed source firmware, which exposed a single device as /dev/video0, so it conveniently 'looked' like a webcam type device. That's not going to be the case moving forwards.

[kbingham]

Once libcamera matures to level of having an actual release or version number, perhaps at that time it will have resolved all the issues and errors that currently prevent the use of these mainstream methods.

It sounds like the most discussion above about not using libcamera is because of the C++... please note that accessing /dev/video0 (without wrapping with our v4l2-compatibility layer) is /not/ libcamera.

You are talking to a raw bayer sensor. It produces bayer formats and requires auto white-balance, and auto-exposure algorithms to be run to get a usable image. (Or manually set values of course)

[Mr-Dave]

Thank you for your comments and clarifying my understanding. I had incorrectly believed that the /dev/videoX devices that were presented on the system were already 'wrapped' and provided by libcamera.

With this clarification, I do not see a path forward for Motion support of the PI camera on systems with the libcamera stack. Motion needs a /dev/videoX device or ffmpeg to support it.

[kbingham]

Adding libcamera support to ffmpeg would be an interesting project for someone indeed.

You can also try using the libcamera v4l2-compatibility layer as mentioned above. There is a script called 'libcamerify' which requests the LD_PRELOAD.

Try something like:

libcamerify motion <motion args>

[Mr-Dave]

Yea, so the lack of documentation/examples of using the libcamera compatibility layer is really one of the big problems here. I'm just a finance executive and not an embedded IT developer so I assumed when I read the libcamera documentation on the compatibility layer that it created the '/dev/videoX' devices.

Now, indicating

It's an LD_Preload and will make a libcamera device look like a V4L2 device so you can use your existing API ...

Does not really resonate with what to do, how to get it to work or what would be the resulting end state device presented. I did look for the libcamerify but does not seem to be present on a fresh install of raspbian.

So, the revised "Help wanted" request on this issue would be to determine and document how to use the libcamera compatibility layer and add it to the Motion documentation as well as provide a generic version of that documentation to the libcamera project for other users.

[kbingham]

We added the libcamerify script at the beginning of February, it looks like it only got updated by the RPi packaging on the 5th March.

libcamerify is in the package 'libcamera-tools' by the looks of it.

[stewartoallen]

You can also try using the libcamera v4l2-compatibility layer as mentioned above. There is a script called 'libcamerify' which requests the LD_PRELOAD.

Try something like:

libcamerify motion <motion args>

this does not appear to work. wrapper says

[1:12:35.183436928] [19246]  INFO Camera camera_manager.cpp:293 libcamera v0.0.0+3424-e68e0f1e
[1:12:35.300471443] [19246] DEBUG V4L2Compat v4l2_compat_manager.cpp:79 Started camera manager
[1:12:35.300658733] [19246] DEBUG V4L2Compat v4l2_camera_proxy.cpp:49 [] open()
[1:12:35.301464923] [19246] DEBUG V4L2Compat v4l2_compat_manager.cpp:163 Opened /dev/video0 -> fd 8
[1:12:35.301732681] [19246] DEBUG V4L2Compat v4l2_camera_proxy.cpp:84 [/dev/video0 (fd:8)] close()

motion log says

[1:ml1] [NTC] [VID] [Mar 12 15:51:34] vid_start: Opening V4L2 device
[1:ml1] [NTC] [VID] [Mar 12 15:51:34] v4l2_device_open: Using videodevice /dev/video0 and input -1
[1:ml1] [ERR] [VID] [Mar 12 15:51:34] v4l2_device_capability: Not a V4L2 device?
[1:ml1] [ERR] [VID] [Mar 12 15:51:34] vid_start: V4L2 device failed to open

libcamera-still and libcamera-hello are working for the camera (a noir raspicam)

having spent an unreasonable amount of time on this, the only reliable workaround so far is to:

1. enable legacy mode
2. edit /boot/config.txt
3. remove or comment out "camera_auto_detect=1"
4. add "start_x=1" and "gpu_mem=128"
5. reboot

[michielhermes]

libcamerify motion <motion args>

Works for me, on a raspberry pi 3 with the HQ camera.

[kbingham]

libcamerify motion <motion args>

Works for me, on a raspberry pi 3 with the HQ camera.

@michielhermes is that definitely with the new libcamera stack enabled on bullseye, and not the legacy video stack?

[anirban1808]

So I can confirm that "libcamerify motion -b" streams a video to a browser on the LAN at :8081.
However, motion is using almost 40% of the CPU at 640x480 30fps.
Also, unable to run motion as a daemon and not sure how to.

[kbingham]

I know above @Mr-Dave has said no C++ in this repository, but Arducam have added libcamera support to mjpg-streamer over in ArduCAM/mjpg-streamer@e503302 so it can be an example of how to wrap the C++ library to a C interface.

I see Motion-Project/motionplus#13 too so perhaps the main libcamera support will happen there.

[Mr-Dave]

The v4l layer has to make libcamera cameras look like /dev/videoX devices. So it could be mapping all four or five /Dev/video nodes to the same camera. Are you able to check what's happening in the motion side around that?

I do not know how to check the nodes used. By using the custom thread names I tracked down the additional threads as being created by the following line in Motion.

fd_device = open(curdev->video_device, O_RDWR|O_CLOEXEC);

The curdev->video_device is the user input of /dev/video0 that is created by libcamera.

I am thinking that this will just be the normal CPU usage for libcamera sending images to v4l2.

[kbingham]

I'll see if we can get the libcamera Thread class to set custom names to help identify them in the future.

[rdukes6514]

For the Raspberry Pi I finally got libcamera to stream MJPG direct HTTP without the need of catching it with vlc, ffplay or anything but a browser. It is even picked up by Motion/Motioneye. I use the pi-attached camera (s) to stream over http. Those streams are picked up by motion(eye) running on a "hub".

I used mjpg-streamer from jacksonliam as modified by ARDUCAM

apt install git gcc g++ cmake libjpeg9-dev
cd /opt
git clone https://github.com/ArduCAM/mjpg-streamer.git
nano /opt/mjpg-streamer/mjpg-streamer-experimental/plugins/input_raspicam/CMakeLists.txt
change all /op/vc/ to /usr/
nano /opt/mjpg-streamer/mjpg-streamer-experimental/plugins/input_libcamera/input_libcamera.cpp
Line 70: " Help for input plugin..: " INPUT_PLUGIN_NAME "\n" \ (insert a space before and after INPUT_PLUGIN_NAME)
cd /opt/mjpg-streamer/mjpg-streamer-experimental
make
make install

Run with
export LD_LIBRARY_PATH=.
./mjpg_streamer -i "input_libcamera" -o "output_http.so -l 0.0.0.0 -p 8081"

[kurgannet]

@kbingham unfortunately I'm getting this error when running motion with libcamerify:

libcamerify -d motion -b

ERROR: ld.so: object '/usr/lib/aarch64-linux-gnu/v4l2-compat.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
[0:motion] [NTC] [ALL] conf_load: Processing thread 0 - config file /etc/motion/motion.conf
[0:motion] [NTC] [ALL] motion_startup: Logging to file (....)

any ideas? Maybe I'm doing something wrong ...

Thanks!

[kbingham]

Wrong elf class sounds like a mismatch in architecture or compilation of the libraries or such.

[kurgannet]

Thanks for the quick response! I have just installed the script via the libcamera-tools package. I'm running Raspberry Pi OS 64-bit on a 8GB raspberry pi 4.

[kbingham]

Is motion also compiled for 64-bit?

The 'file' command should tell you the architecture of the binaries:

file `which motion`

[kurgannet]

Oh! that's it! Thanks! Is there any Raspberry Pi 64-bits releases? The one I've installed is 4.4.0-1 armhf and it's 32 bits.

[Mr-Dave]

You would have to build from source.

[zizumara]

@stewartoallen I tried your workaround technique and it didn't work for me. The motion log shows the same "V4L2 device failed to open" message. However, my situation might be a little unique.

I'm trying to replicate a prior working project which used a Pi Zero W and an Arducam IMX477 HQ Pi camera with a switchable IR-cut filter running on the Buster OS. I'm trying to upgrade my project with a Pi Zero 2 W running the Bullseye OS using the latest version of their camera (https://www.uctronics.com/camera-modules/camera-for-raspberry-pi/high-quality-camera-raspberry-pi-12mp-imx477/arducam-12mp-imx477-ir-cut-filter-auto-switch-camera-for-raspberry-pi-b0270.html), following all the same steps that I used to successfully set up my original working project (except installing Bullseye and Motion 4.4.0). However, the supplier states that this version of their camera is ONLY compatible with the Bullseye OS, but does not provide any further specifics. I have inquired as to whether they still sell the legacy version of this product, but the only answer I got back was that the current product is only compatible with Bullseye (so I guess that's a "no").

I can get the new camera to respond properly to libcamera-hello, but only if I set camera_auto_detect=1 and dtoverlay=imx477 in /boot/config.txt. I have tried your workaround steps (i.e. enable legacy, remove camera_auto_detect, set start_x=1, and set gpu_mem=128), but when I run motion the V4L2 device fails to open.

Below is what I get from the motion log:

[0:motion] [NTC] [ALL] conf_load: Processing thread 0 - config file ./motion.conf
[0:motion] [NTC] [ALL] motion_startup: Logging to syslog
[0:motion] [NTC] [ALL] motion_startup: Motion 4.4.0 Started
[0:motion] [NTC] [ALL] motion_startup: Using default log type (ALL)
[0:motion] [NTC] [ALL] motion_startup: Using log type (ALL) log level (INF)
[0:motion] [INF] [ALL] conf_output_parms: Writing configuration parameters from all files (1):
[0:motion] [INF] [ALL] Thread 0 - Config file: ./motion.conf
[0:motion] [INF] [ALL] daemon off
[0:motion] [INF] [ALL] setup_mode off
[0:motion] [INF] [ALL] pid_file
[0:motion] [INF] [ALL] log_file
[0:motion] [INF] [ALL] log_level 7
[0:motion] [INF] [ALL] log_type ALL
[0:motion] [INF] [ALL] quiet on
[0:motion] [INF] [ALL] native_language on
[0:motion] [INF] [ALL] watchdog_tmo 30
[0:motion] [INF] [ALL] watchdog_kill 10
[0:motion] [INF] [ALL] camera_name
[0:motion] [INF] [ALL] camera_id 0
[0:motion] [INF] [ALL] target_dir /motion
[0:motion] [INF] [ALL] video_device /dev/video0
[0:motion] [INF] [ALL] video_params
[0:motion] [INF] [ALL] auto_brightness 0
[0:motion] [INF] [ALL] tuner_device
[0:motion] [INF] [ALL] roundrobin_frames 1
[0:motion] [INF] [ALL] roundrobin_skip 1
[0:motion] [INF] [ALL] roundrobin_switchfilter off
[0:motion] [INF] [ALL] netcam_url
[0:motion] [INF] [ALL] netcam_params
[0:motion] [INF] [ALL] netcam_high_url
[0:motion] [INF] [ALL] netcam_high_params
[0:motion] [INF] [ALL] netcam_userpass
[0:motion] [INF] [ALL] mmalcam_name vc.ril.camera
[0:motion] [INF] [ALL] mmalcam_params -ex sports -ss 250 -ag 3 -dg 1 -awb greyworld
[0:motion] [INF] [ALL] width 640
[0:motion] [INF] [ALL] height 480
[0:motion] [INF] [ALL] framerate 3
[0:motion] [INF] [ALL] minimum_frame_time 0
[0:motion] [INF] [ALL] rotate 0
[0:motion] [INF] [ALL] flip_axis none
[0:motion] [INF] [ALL] locate_motion_mode off
[0:motion] [INF] [ALL] locate_motion_style box
[0:motion] [INF] [ALL] text_left CAMERA1
[0:motion] [INF] [ALL] text_right %Y-%m-%d\n%T-%q
[0:motion] [INF] [ALL] text_changes on
[0:motion] [INF] [ALL] text_scale 1
[0:motion] [INF] [ALL] text_event %Y%m%d%H%M%S
[0:motion] [INF] [ALL] emulate_motion off
[0:motion] [INF] [ALL] pause off
[0:motion] [INF] [ALL] threshold 20000
[0:motion] [INF] [ALL] threshold_maximum 0
[0:motion] [INF] [ALL] threshold_tune off
[0:motion] [INF] [ALL] noise_level 32
[0:motion] [INF] [ALL] noise_tune on
[0:motion] [INF] [ALL] despeckle_filter EedDl
[0:motion] [INF] [ALL] area_detect
[0:motion] [INF] [ALL] mask_file
[0:motion] [INF] [ALL] mask_privacy
[0:motion] [INF] [ALL] smart_mask_speed 5
[0:motion] [INF] [ALL] lightswitch_percent 0
[0:motion] [INF] [ALL] lightswitch_frames 5
[0:motion] [INF] [ALL] minimum_motion_frames 2
[0:motion] [INF] [ALL] event_gap 10
[0:motion] [INF] [ALL] pre_capture 1
[0:motion] [INF] [ALL] post_capture 0
[0:motion] [INF] [ALL] on_event_start
[0:motion] [INF] [ALL] on_event_end
[0:motion] [INF] [ALL] on_picture_save
[0:motion] [INF] [ALL] on_area_detected
[0:motion] [INF] [ALL] on_motion_detected
[0:motion] [INF] [ALL] on_movie_start
[0:motion] [INF] [ALL] on_movie_end
[0:motion] [INF] [ALL] on_camera_lost
[0:motion] [INF] [ALL] on_camera_found
[0:motion] [INF] [ALL] picture_output on
[0:motion] [INF] [ALL] picture_output_motion off
[0:motion] [INF] [ALL] picture_type jpeg
[0:motion] [INF] [ALL] picture_quality 100
[0:motion] [INF] [ALL] picture_exif -ex sports -ss 250 -ag 3 -dg 1 -awb greyworld threshold 20000
[0:motion] [INF] [ALL] picture_filename %Y%m%d%H%M%S-%q
[0:motion] [INF] [ALL] snapshot_interval 0
[0:motion] [INF] [ALL] snapshot_filename %v-%Y%m%d%H%M%S-snapshot
[0:motion] [INF] [ALL] movie_output off
[0:motion] [INF] [ALL] movie_output_motion off
[0:motion] [INF] [ALL] movie_max_time 60
[0:motion] [INF] [ALL] movie_bps 400000
[0:motion] [INF] [ALL] movie_quality 45
[0:motion] [INF] [ALL] movie_codec mkv
[0:motion] [INF] [ALL] movie_duplicate_frames off
[0:motion] [INF] [ALL] movie_passthrough off
[0:motion] [INF] [ALL] movie_filename %t-%v-%Y%m%d%H%M%S
[0:motion] [INF] [ALL] movie_extpipe_use off
[0:motion] [INF] [ALL] movie_extpipe
[0:motion] [INF] [ALL] timelapse_interval 0
[0:motion] [INF] [ALL] timelapse_mode daily
[0:motion] [INF] [ALL] timelapse_fps 30
[0:motion] [INF] [ALL] timelapse_codec mpg
[0:motion] [INF] [ALL] timelapse_filename %Y%m%d-timelapse
[0:motion] [INF] [ALL] video_pipe
[0:motion] [INF] [ALL] video_pipe_motion
[0:motion] [INF] [ALL] webcontrol_port 8080
[0:motion] [INF] [ALL] webcontrol_ipv6 off
[0:motion] [INF] [ALL] webcontrol_localhost on
[0:motion] [INF] [ALL] webcontrol_parms 0
[0:motion] [INF] [ALL] webcontrol_interface 0
[0:motion] [INF] [ALL] webcontrol_auth_method 0
[0:motion] [INF] [ALL] webcontrol_authentication
[0:motion] [INF] [ALL] webcontrol_tls off
[0:motion] [INF] [ALL] webcontrol_cert
[0:motion] [INF] [ALL] webcontrol_key
[0:motion] [INF] [ALL] webcontrol_header_params
[0:motion] [INF] [ALL] webcontrol_lock_minutes 5
[0:motion] [INF] [ALL] webcontrol_lock_attempts 5
[0:motion] [INF] [ALL] webcontrol_lock_max_ips 25
[0:motion] [INF] [ALL] stream_port 8081
[0:motion] [INF] [ALL] stream_localhost off
[0:motion] [INF] [ALL] stream_auth_method 0
[0:motion] [INF] [ALL] stream_authentication
[0:motion] [INF] [ALL] stream_tls off
[0:motion] [INF] [ALL] stream_header_params
[0:motion] [INF] [ALL] stream_preview_scale 25
[0:motion] [INF] [ALL] stream_preview_newline off
[0:motion] [INF] [ALL] stream_preview_method 0
[0:motion] [INF] [ALL] stream_quality 50
[0:motion] [INF] [ALL] stream_grey off
[0:motion] [INF] [ALL] stream_motion off
[0:motion] [INF] [ALL] stream_maxrate 1
[0:motion] [INF] [ALL] stream_limit 0
[0:motion] [INF] [ALL] database_type
[0:motion] [INF] [ALL] database_dbname
[0:motion] [INF] [ALL] database_host localhost
[0:motion] [INF] [ALL] database_port 0
[0:motion] [INF] [ALL] database_user
[0:motion] [INF] [ALL] database_password
[0:motion] [INF] [ALL] database_busy_timeout 0
[0:motion] [INF] [ALL] sql_log_picture off
[0:motion] [INF] [ALL] sql_log_snapshot off
[0:motion] [INF] [ALL] sql_log_movie off
[0:motion] [INF] [ALL] sql_log_timelapse off
[0:motion] [INF] [ALL] sql_query_start
[0:motion] [INF] [ALL] sql_query_stop
[0:motion] [INF] [ALL] sql_query
[0:motion] [INF] [ALL] track_type 0
[0:motion] [INF] [ALL] track_auto off
[0:motion] [INF] [ALL] track_port
[0:motion] [INF] [ALL] track_motorx 0
[0:motion] [INF] [ALL] track_motorx_reverse off
[0:motion] [INF] [ALL] track_motory 0
[0:motion] [INF] [ALL] track_motory_reverse off
[0:motion] [INF] [ALL] track_maxx 0
[0:motion] [INF] [ALL] track_minx 0
[0:motion] [INF] [ALL] track_maxy 0
[0:motion] [INF] [ALL] track_miny 0
[0:motion] [INF] [ALL] track_homex 128
[0:motion] [INF] [ALL] track_homey 128
[0:motion] [INF] [ALL] track_iomojo_id 0
[0:motion] [INF] [ALL] track_step_angle_x 10
[0:motion] [INF] [ALL] track_step_angle_y 10
[0:motion] [INF] [ALL] track_move_wait 10
[0:motion] [INF] [ALL] track_speed 255
[0:motion] [INF] [ALL] track_stepsize 40
[0:motion] [INF] [ALL] track_generic_move
[0:motion] [INF] [ALL] camera
[0:motion] [INF] [ALL] camera_dir
[0:motion] [NTC] [STR] webu_start_strm: Starting all camera streams on port 8081
[0:motion] [NTC] [STR] webu_strm_ntc: Started camera 0 stream on port 8081
[0:motion] [NTC] [STR] webu_start_ctrl: Starting webcontrol on port 8080
[0:motion] [NTC] [STR] webu_start_ctrl: Started webcontrol on port 8080
[0:motion] [NTC] [ENC] ffmpeg_global_init: ffmpeg libavcodec version 58.91.100 libavformat version 58.45.100
[0:motion] [NTC] [ALL] translate_init: Language: English
[0:motion] [NTC] [ALL] motion_start_thread: Camera ID: 0 is from ./motion.conf
[0:motion] [NTC] [ALL] motion_start_thread: Camera ID: 0 Camera Name: (null) Device: /dev/video0
[0:motion] [NTC] [ALL] main: Waiting for threads to finish, pid: 1357
[1:ml1] [NTC] [ALL] motion_init: Camera 0 started: motion detection Enabled
[1:ml1] [NTC] [VID] vid_start: Opening V4L2 device
[1:ml1] [NTC] [VID] v4l2_device_open: Using videodevice /dev/video0 and input -1
[1:ml1] [NTC] [VID] v4l2_device_capability: - VIDEO_CAPTURE
[1:ml1] [NTC] [VID] v4l2_device_capability: - READWRITE
[1:ml1] [NTC] [VID] v4l2_device_capability: - STREAMING
[1:ml1] [NTC] [VID] v4l2_input_select: Name = "unicam-image"- CAMERA
[1:ml1] [NTC] [VID] v4l2_norm_select: Device does not support specifying PAL/NTSC norm
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: Configuration palette index 17 (YU12) for 640x480 doesn't work.
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: Supported palettes:
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (0) YUYV (YUYV 4:2:2)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (1) UYVY (UYVY 4:2:2)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (2) YVYU (YVYU 4:2:2)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (3) VYUY (VYUY 4:2:2)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (4) RGBP (16-bit RGB 5-6-5)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (5) RGBR (16-bit RGB 5-6-5 BE)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (6) RGBO (16-bit A/XRGB 1-5-5-5)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (7) RGBQ (16-bit A/XRGB 1-5-5-5 BE)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (8) RGB3 (24-bit RGB 8-8-8)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (9) BGR3 (24-bit BGR 8-8-8)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (10) RGB4 (32-bit A/XRGB 8-8-8-8)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (11) BA81 (8-bit Bayer BGBG/GRGR)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (12) GBRG (8-bit Bayer GBGB/RGRG)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (13) GRBG (8-bit Bayer GRGR/BGBG)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (14) RGGB (8-bit Bayer RGRG/GBGB)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (15) pBAA (10-bit Bayer BGBG/GRGR Packed)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (16) BG10 (10-bit Bayer BGBG/GRGR)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (17) pGAA (10-bit Bayer GBGB/RGRG Packed)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (18) GB10 (10-bit Bayer GBGB/RGRG)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (19) pgAA (10-bit Bayer GRGR/BGBG Packed)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (20) BA10 (10-bit Bayer GRGR/BGBG)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (21) pRAA (10-bit Bayer RGRG/GBGB Packed)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (22) RG10 (10-bit Bayer RGRG/GBGB)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (23) pBCC (12-bit Bayer BGBG/GRGR Packed)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (24) BG12 (12-bit Bayer BGBG/GRGR)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (25) pGCC (12-bit Bayer GBGB/RGRG Packed)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (26) GB12 (12-bit Bayer GBGB/RGRG)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (27) pgCC (12-bit Bayer GRGR/BGBG Packed)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (28) BA12 (12-bit Bayer GRGR/BGBG)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (29) pRCC (12-bit Bayer RGRG/GBGB Packed)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (30) RG12 (12-bit Bayer RGRG/GBGB)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (31) pBEE (14-bit Bayer BGBG/GRGR Packed)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (32) BG14 (14-bit Bayer BGBG/GRGR)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (33) pGEE (14-bit Bayer GBGB/RGRG Packed)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (34) GB14 (14-bit Bayer GBGB/RGRG)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (35) pgEE (14-bit Bayer GRGR/BGBG Packed)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (36) GR14 (14-bit Bayer GRGR/BGBG)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (37) pREE (14-bit Bayer RGRG/GBGB Packed)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (38) RG14 (14-bit Bayer RGRG/GBGB)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (39) GREY (8-bit Greyscale)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (40) Y10P (10-bit Greyscale (MIPI Packed))
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (41) Y10 (10-bit Greyscale)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (42) Y12P (12-bit Greyscale (MIPI Packed))
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (43) Y12 (12-bit Greyscale)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (44) Y14P (14-bit Greyscale (MIPI Packed))
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (45) Y14 (14-bit Greyscale)
[1:ml1] [NTC] [VID] v4l2_pixfmt_set: Testing palette Y12 (640x480)
[1:ml1] [NTC] [VID] v4l2_pixfmt_set: Using palette Y12 (640x480)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: Selected palette Y12
[1:ml1] [INF] [VID] v4l2_fps_set: Trying to set fps to 3
[1:ml1] [ERR] [VID] v4l2_fps_set: Error setting fps. Return code -1
[1:ml1] [INF] [VID] v4l2_fps_set: Device set fps to 3
[1:ml1] [INF] [VID] v4l2_ctrls_list: No Controls found for device
[1:ml1] [ERR] [VID] v4l2_mmap_set: Error starting stream. VIDIOC_STREAMON: Invalid argument
[1:ml1] [ERR] [VID] vid_start: V4L2 device failed to open

I have even tried the libcamerify script to no avail.

Can you offer any suggestions on getting this to work with Bullseye? I might try going back to the Pi Zero W to see if I get different results. I can't go to a Pi 3 or Pi 4 because those exceed the size and power requirements for my project. I could revert to using Buster, but I can't find any camera with the equivalent features (HQ with a switchable IR-cut filter). If push comes to shove, I could cannibalize the older version of camera from my existing project, but I'd rather avoid that if at all possible.

[Mr-Dave]

I'm not sure why libcamerify motion would not work for you. I tested it and it worked on fresh Bullseye version of a PI zero. I'd say to revert to the default settings, get it to respond to libcamera-hello then try the libcamerify motion

[zizumara]

@Mr-Dave That did it! Thanks!

BTW, it's a Pi Zero 2 W. The "default" configuration for this particular Pi HQ camera requires camera_auto_detect=0 and dtoverlay=imx477 in /boot/config.txt.

[bad-friday]

@Mr-Dave That did it! Thanks!

For me too

[Mr-Dave]

Updated instructions in commit ae63db8

[zizumara]

In my previous project on the Pi Zero W with Buster, motion worked with the height and width set to 800x480. In my current project with a Pi Zero 2 W with Bullseye, motion fails with a segmentation fault if I use 800x480. I have tried various combinations. The only ones that have worked so far are ones that preserve the 4:3 aspect ratio (e.g. 640x480, 960x720). What are the valid combinations of Motion width and height in Bullseye?

[Mr-Dave]

In my previous project on the Pi Zero W with Buster, motion worked with the height and width set to 800x480. In my current project with a Pi Zero 2 W with Bullseye, motion fails with a segmentation fault if I use 800x480. I have tried various combinations. The only ones that have worked so far are ones that preserve the 4:3 aspect ratio (e.g. 640x480, 960x720). What are the valid combinations of Motion width and height in Bullseye?

This is a different issue and something upstream. Change the palette being used in Motion and it will work.

[zizumara]

Thanks. Closer inspection of motion output revealed the supported formats for the IMX477 camera as follows:

[1:ml1] [NTC] [VID] v4l2_pixfmt_select: Supported palettes:
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (0) NV21 (Y/CrCb 4:2:0)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (1) YU12 (Planar YUV 4:2:0)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (2) NV12 (Y/CbCr 4:2:0)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (3) YV12 (Planar YVU 4:2:0)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (4) XB24 (32-bit RGBX 8-8-8-8)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (5) RGB3 (24-bit RGB 8-8-8)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (6) BGR3 (24-bit BGR 8-8-8)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (7) XR24 (32-bit BGRX 8-8-8-8)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (8) RGBP (16-bit RGB 5-6-5)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (9) YVYU (YVYU 4:2:2)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (10) YUYV (YUYV 4:2:2)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (11) VYUY (VYUY 4:2:2)
[1:ml1] [NTC] [VID] v4l2_pixfmt_select: (12) UYVY (UYVY 4:2:2)

If I omit video_params from my configuration and use dimensions of 800x480 pixels, Motion defaults to YU12 and then crashes with a segmentation fault. I then included the video_params palette setting in my configuration tested each of the 20 palettes. What's interesting is that if the palette configured does not match one in the supported palettes list, Motion uses the UYVY palette (not the YU12 palette) and does not crash. Only the YU12 palette (either by default or by intentional selection) causes a segmentation fault. The other two palettes common to both lists, RGB3 and YUYV, can be used without Motion crashing. So I have a total of three palettes that I can use.

Again, thanks for the quick response.

[Mr-Dave]

The issue has been identified. For this camera, pixel format and resolution, the camera is providing a different stride (bytes per line) than the width. Specify the width as the bytes per line as reported in the debug Motion log.

[1:ml1] [DBG] [VID] v4l2_pixfmt_set: Bytesperlines 832 sizeimage 599040 colorspace 00000008

Resolved in commit d859a3e Motion will now automatically change the configuration width value provided to match the bytes per line.

[bad-friday]

I can follow this discussion what I do not understand: what does ISP mean?

[PeterHolik]

Sorry, your stride patch does not work for my USB Capture Card with an analog camera setting with 512 height 384

v4l2-ctl --get-fmt-video

Format Video Capture:
Width/Height : 512/384
Pixel Format : 'YUYV' (YUYV 4:2:2)
Field : Interlaced
Bytes per Line : 1024
Size Image : 393216
Colorspace : SMPTE 170M
Transfer Function : Default (maps to Rec. 709)
YCbCr/HSV Encoding: Default (maps to ITU-R 601)
Quantization : Default (maps to Limited Range)

v4l2-ctl --list-formats-ext

ioctl: VIDIOC_ENUM_FMT
Type: Video Capture

[0]: 'YUYV' (YUYV 4:2:2)
	Size: Stepwise 144x115 - 720x576 with step 1/1
[1]: 'RGBP' (16-bit RGB 5-6-5)
	Size: Stepwise 144x115 - 720x576 with step 1/1
[2]: 'RGGB' (8-bit Bayer RGRG/GBGB)
	Size: Stepwise 144x115 - 720x576 with step 1/1
[3]: 'BA81' (8-bit Bayer BGBG/GRGR)
	Size: Stepwise 144x115 - 720x576 with step 1/1
[4]: 'GRBG' (8-bit Bayer GRGR/BGBG)
	Size: Stepwise 144x115 - 720x576 with step 1/1
[5]: 'GBRG' (8-bit Bayer GBGB/RGRG)
	Size: Stepwise 144x115 - 720x576 with step 1/1
[6]: '411P' (Planar YUV 4:1:1)
	Size: Stepwise 144x115 - 720x576 with step 1/1

[bad-friday]

I've testet my settings. For native motion they are not ok. With libcamerify motion the settings seem to be correct.
The logs of the two test are spareted by a $$$$$$$$$$$$$$$$$-eyecatcher
motion.log

[zizumara]

I can follow this discussion what I do not understand: what does ISP mean?

ISP stands for Image Signal Processor. Google definition:
"As the name implies, the Image Signal Processor (ISP) is used for processing images in embedded vision camera systems. The ISP also performs other operations on the captured image such as demosaicing, denoising, and auto functions that help deliver an enhanced image."

[bad-friday]

I have a lot of distortions on the movies. Screen with pink stripes (broad), black & white distortions.
The camera is about 3m apart, connected with the «Arducam CSI to HDMI Cable Extension Module» over HDMI.
One side with 30cm and the other side with 60cm flat ribbon cable.