Replies: 10 comments 21 replies
-
|
Probably want to validate that libcamerify works with other applications. e.g. ffmpeg, ffplay, v4l2-utils, vlc, etc. Possibly also look for whether libcamerify created a different(additional?) device (e.g. /dev/video1) rather than just /dev/video0 |
Beta Was this translation helpful? Give feedback.
-
|
Okay, I'll try to debug a bit further to see whether this issue is specific to motion. My current workaround is to use a libcamera-based Python script to create an mjpeg server, which I then access locally in motion. There's a slight CPU hit but it seems to be working okay. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Sorry the link was lost: kbingham/libcamera#69 |
Beta Was this translation helpful? Give feedback.
-
|
Looking at the logs - the libcamerify v4l2 layer gets called for 'open' - but never seems to get called for any of the ioctls on that device, so we can't intercept the calls and use libcamera. Does motion do anything that would prevent an LD_PRELOAD library from intercepting ioctls to a V4L2 video device? (That's what I think is failing) |
Beta Was this translation helpful? Give feedback.
-
|
From the other linked issue, the My first impression is that it is a ARM64 related issue. (The 32 bit works fine on my PI) I not own any ARM64 capable hardware however so it impossible for me to validate. I suppose I'd need you to change over to 32 bit image and validate that. For transparency, the specific start up section of the code is here. Motion starts by initializing the default parameters, gets user parameters, opens the device, checks the compatibility of the device, selects the input channel, applies user parameters, etc. From the other message log, the call to check for VIDIOC_QUERYCAP on the start up processes is where it fails. At this point in the startup process, virtually nothing has occurred. Motion is opening the device and very first call to any ioctl fails. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, once I saw that the querycap isn't being called - the input -1 was clearly a red herring. This call: Line 1501 in ab0a463 Doesn't call into the libcamera v4l2 layer at all - it could very well be that there's something specific about 64 bit ioctls that we might have missed. |
Beta Was this translation helpful? Give feedback.
-
|
Though I'm still confused by that - as I can run "libcamerify v4l2-compliance" - on arm64 and the calls all get intercepted from there. |
Beta Was this translation helpful? Give feedback.
-
|
I forgot to add a couple of suggestions:
|
Beta Was this translation helpful? Give feedback.
-
|
Uh ... unless it's not a libcamera bug - It could also be a casting bug in xioctl: Line 132 in ab0a463 |
Beta Was this translation helpful? Give feedback.
-
|
Yes - changing to correctly use the unsigned long request, instead of int request makes this work. I'm not sure yet what the repurcussions are there - whether libcamera should always cast out the top 32 bits, or if the applications should also make sure not to signextend ... (Or both) |
Beta Was this translation helpful? Give feedback.
-
|
Thanks. I wouldn't have ever picked that up as to the cause. |
Beta Was this translation helpful? Give feedback.
-
It's definitely hard to spot and subtle. We can catch it, and report it in libcamera so I'll submit a patch for that. But it's still worth identifying the right fix here too. I think it's fine to just always use unsigned long. |
Beta Was this translation helpful? Give feedback.
-
|
Pretty cool that you found the reason for the problem, it's really a ver subtle thing to pin down. Ehat do you think, when will it make it's way into the source after the discussion of the proper handling is solved? |
Beta Was this translation helpful? Give feedback.
-
|
@joeschmitt Motionplus would be an option for you now. I just added functionality for revising / changing all the controls on the camera so that provides a lot more flexibility than libcamerify. But...you would need to check the documentation on the differences to ensure that Motionplus still meets your needs. |
Beta Was this translation helpful? Give feedback.
-
|
Ok I will check the docu. I guess I still need the libcamerify script, or? |
Beta Was this translation helpful? Give feedback.
-
|
You shouldn't need to use libcamerify with motionplus as I understand it. That's got 'native' libcamera integration. |
Beta Was this translation helpful? Give feedback.
-
That is correct. Motionplus provides native support via the paramater |
Beta Was this translation helpful? Give feedback.
-
|
https://busybox.busybox.narkive.com/jynzqsFW/patch-fix-ioctl-wrappers-for-64-bit-systems Looks like the use of an old xioctl here in motion is the fault. |
Beta Was this translation helpful? Give feedback.
-
|
Digging further in here - this may be too harsh a statement. The Linux kernel does seem to accept an unsigned int here, which means that the upper 32 bits should be ignored. So this definitely gets a fix in libcamera. It's probably optional if motion makes any change here. |
Beta Was this translation helpful? Give feedback.
-
|
It will be revised in Motion. It has already been implemented in Motionplus. I'll also be adding a -Wconversion to Motionplus and probably Motion to fortify them better and identify issues such as this. |
Beta Was this translation helpful? Give feedback.
-
|
Hi. My attempt to use motionplus wasn't successful. This means I was able to build an start the app but in the web control view I never got a video and als not on the "normal" way. Nevertheless, thank you very much for your help and feedback |
Beta Was this translation helpful? Give feedback.
-
|
Closing issue/discussion. The Motion code has been revised to use "unsigned long" in the ioctl call |
Beta Was this translation helpful? Give feedback.
-
|
completing the loops here as well - the alternate/corresponding 'fix' in libcamera was also merged at https://git.libcamera.org/libcamera/libcamera.git/commit/?id=f7a9f141569115a3da9edb758e3a5adbe723c330 in libcamera v0.1.0 |
Beta Was this translation helpful? Give feedback.
-
|
I can confirm that installing everything from sources (libcamera/libcam-apps/motion) from default branches works: Motion 4.5.1+git20230416-c28d41b
The most important thing was building motion from master, but thankfully docs are straightforward. |
Beta Was this translation helpful? Give feedback.
-
Did you read the guide?
Yes
What is the base version number of Motion being used?
4.5.x
What was the install method?
Installed via package tool
What is base architecture?
ARM-64bit
What is the distro being used?
Raspbian
Disto version number
bullseye
Camera type(s) being used?
PI cam via libcamerify
Describe the issue/problem and steps to reproduce
I'm experiencing a similar issue to that discussed in #1434, i.e. calling
motionwithlibcamerifyis throwing the following error:This is a fresh install of motion on Raspberry Pi OS Bullseye (64-bit). The camera is a Raspberry Pi Camera Module 1 but I've recently purchased a Raspberry Pi Camera Module 3 which won't run in legacy mode, hence libcamera being the only option going forwards.
Relevant Motion log output (at log_level 8)
Beta Was this translation helpful? Give feedback.
All reactions