Rpi Cam Web Interface doesnt seem to work on Bullseye

[spookytheripper]

Hey everyone,

I just tried to install it on a fresh Raspbian Bullseye and it seems not to work. From my understanding Bullseye retired RaspiMJPEG and moved to libcamera.

I managed to "run the install.sh" by using php 7.4 (instead of 7.3), but when i try to run start.sh it cant find raspimjpeg. "raspimjpeg: command not found"

Is there a way to install raspimjpeg or make it work with libcamera?

(and on the RPi website I cant download an ISO of the older Buster OS)

[roberttidey]

I haven't tried bullseye yet as it has only just been released, but hope to test and see what issues there are over the next few days.

I don't know what the statement 'Bullseye retired RaspiMJPEG and moved to libcamera.' means. RaspiMJPEG is a separate build from the OS and the binary is included in the RPi Cam installer.

If raspimjpeg cannot be found (should be in /opt/vc/bin) then the install script log (install.txt) should show a problem.

In the meantime previous buster OS images can be found in the archives

https://downloads.raspberrypi.org/raspios_armhf/images/

May 2021 should be the latest

[spookytheripper]

Hey Robert, thanks for the link.

Sorry if i didn't express myself right, English is not my native language and I don't have a very technical background. Here is their wording from the blogpost (https://www.raspberrypi.com/news/raspberry-pi-os-debian-bullseye/)

"The driver used by Raspberry Pi to access camera modules has now been replaced with libcamera, a standard Linux API. As with the video driver change, this means less closed-source proprietary code, and makes it easier for third parties to develop new camera hardware and software.

For anyone who has written camera-based applications in the past, this is a very significant change, and is too large to be covered here. There will be a blog post dedicated to the new camera driver published soon, so watch this space!"

EDIT: there is nothing in /opt/ in bullseye beside pigipio, i tried running the installer and check the install.txt but i couldnt find the error message in it. i took a screenshot tho: https://imgur.com/a/WBhqmHf , i'm not sure where it took the .bak it saved in /etc/ i guess i could try placing it in the /opt/vc/bin/ folder?

[roberttidey]

I am starting to do a bit of investigation.

It looks like the camera changes are significant. The set of previous camera apps including raspistill and raspivid which were the standard apps included in the OS are also missing. That means the /opt/vc/bin folder where these would normally be their home doesn't even exist any more.

This is not well documented yet and there seems to be replacements called libcamera-still and libcamera-vid which are not compatible with previous usage. https://marketresearchtelecast.com/raspberry-pi-os-updated-based-on-debian-bullseye/197901/

This may take a bit of sorting out.

[roberttidey]

There is more info about the change in the Raspberry camera documentation.

https://www.raspberrypi.com/documentation/accessories/camera.html

The bit I don't like here as that the new method does not make so much use of the GPU and will therefore struggle on lower performance Pis. As one of the key benefits of the raspimjpeg was that it gave good performance even on Pi Zeros (which a lot of camera apps use) this is a significant drawback.

[mfraser]

On 09/11/2021 13:50, roberttidey wrote:

There is more info about the change in the Raspberry camera documentation.

https://www.raspberrypi.com/documentation/accessories/camera.html https://www.raspberrypi.com/documentation/accessories/camera.html

The bit I don't like here as that the new method does not make so much use of the GPU and will therefore struggle on lower performance Pis. As one of the key benefits of the raspimjpeg was that it gave good performance even on Pi Zeros (which a lot of camera apps use) this is a significant drawback.

This may help, but there still seems to be issues. https://forums.raspberrypi.com/viewtopic.php?t=323390

[roberttidey]

Thanks. I had seen that follow up and am asking some questions under that topic to see if this could be a viable method at least in the short term.

[roberttidey]

I have a method to allow this to run on Bullseye which seems to work OK. I posted details on the Raspberry forum https://forums.raspberrypi.com/viewtopic.php?t=63276&start=5325

Currently it needs a few manual steps before running the normal install but I'll look into automating these or having a separate Bullseye preparation script.

[roberttidey]

The install script now detects Bullseye and sets up legacy camera support.

[MichaIng]

The Bullseye raspimjpeg binary requires a rebuild against latest libraspberrypi0 as it does not contain shared libraries named like libmmal_core.so anymore but named libmmal_core.so.0. Because of this, the binary fails as it does not find the shared object it was linked against.

For reference: https://github.com/MichaIng/DietPi/issues/5000#issuecomment-981091417

[roberttidey]

I did the first build of raspimjpeg on bullseye (11 Nov 2021) using the latest release and updates on that date. That works OK under the legacy stack.

Are you saying you have done a later update and it is not working.

I can do another build to check.

[MichaIng]

It is strange, as at that date the package should be with the new library names already. However, do the following to replicate:

cd /tmp
curl -sSfLO 'https://github.com/silvanmelchior/RPi_Cam_Web_Interface/raw/master/bin/raspimjpeg'
ldd raspimjpeg

And you get:

...
/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so => /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so (0x76fb9000)
libmmal_core.so => /usr/lib/arm-linux-gnueabihf/libmmal_core.so (0x76f9a000)
libmmal_util.so => /usr/lib/arm-linux-gnueabihf/libmmal_util.so (0x76f7b000)
libmmal_vc_client.so => /usr/lib/arm-linux-gnueabihf/libmmal_vc_client.so (0x76f5d000)
libbcm_host.so => /usr/lib/arm-linux-gnueabihf/libbcm_host.so (0x76f37000)
libvcsm.so => /usr/lib/arm-linux-gnueabihf/libvcsm.so (0x76f1c000)
libvchiq_arm.so => /usr/lib/arm-linux-gnueabihf/libvchiq_arm.so (0x76f05000)
libvcos.so => /usr/lib/arm-linux-gnueabihf/libvcos.so (0x76ee9000)
...

These libraries do not exist, but the same ones with .0 appended. Not sure how the linker could have done this when the libraspberrypi0 package was definitely up-to-date, i.e. the now linked libraries did not exist.

To verify the content of the package:

# dpkg -L libraspberrypi0
...
/usr/lib/arm-linux-gnueabihf/libbcm_host.so.0
/usr/lib/arm-linux-gnueabihf/libcontainers.so.0
/usr/lib/arm-linux-gnueabihf/libdebug_sym.so.0
/usr/lib/arm-linux-gnueabihf/libdtovl.so.0
/usr/lib/arm-linux-gnueabihf/libmmal.so.0
/usr/lib/arm-linux-gnueabihf/libmmal_components.so.0
/usr/lib/arm-linux-gnueabihf/libmmal_core.so.0
/usr/lib/arm-linux-gnueabihf/libmmal_util.so.0
/usr/lib/arm-linux-gnueabihf/libmmal_vc_client.so.0
/usr/lib/arm-linux-gnueabihf/libvchiq_arm.so.0
/usr/lib/arm-linux-gnueabihf/libvcos.so.0
/usr/lib/arm-linux-gnueabihf/libvcsm.so.0
...

[roberttidey]

Thanks for the report.

I think the issue is that my test machine has the userland development environment on which built and installed those libraries referenced at the same time as raspimjpeg builds, so they are resolved and it works OK. Buster already has those libraries to support the previous MMAL camera applications.

I did update the userland to the latest raspberry version before I did the build but it does not build and link the .0 versions. It is not clear to me at the moment if those are going to be compatible.

I need to do some more investigation. It is possible I will need to include the libraries in the installation if they are not compatible.

[MichaIng]

They are compatible, it's really only the names. Creating symlinks for all those without .0 pointing to the ones with .0 works around the issue.

On Buster, the userland/package contains still the old style library names, so it must be compiled on a Bullseye system, respectively with the libraspberrypi0 package from the Bullseye suite of archive.raspberrrypi.org.

[roberttidey]

I was just coming to same conclusions. On my test machine there are sym links e.g. for ls -l /usr/lib/arm-linux-gnueabihf/libmmal* `-rw-r--r-- 1 root root 46776 Oct 12 16:30 libmmal_components.so.0

lrwxrwxrwx 1 root root 17 Oct 12 16:30 libmmal_core.so -> libmmal_core.so.0

-rw-r--r-- 1 root root 59228 Oct 12 16:30 libmmal_core.so.0

lrwxrwxrwx 1 root root 12 Oct 12 16:30 libmmal.so -> libmmal.so.0

-rw-r--r-- 1 root root 13732 Oct 12 16:30 libmmal.so.0

lrwxrwxrwx 1 root root 17 Oct 12 16:30 libmmal_util.so -> libmmal_util.so.0

-rw-r--r-- 1 root root 59228 Oct 12 16:30 libmmal_util.so.0

lrwxrwxrwx 1 root root 22 Oct 12 16:30 libmmal_vc_client.so -> libmmal_vc_client.so.0

-rw-r--r-- 1 root root 46804 Oct 12 16:30 libmmal_vc_client.so.0 `

[MichaIng]

Ah okay, that explains it, I guess 🙂. However, those are not content of and not created via libraspberrypi0 package maintainer script, so would be good to have a build which uses the .0 ones directly.

[GeekyTim]

The Buster camera software is not yet ready. We're awaiting Raspberry Pi to develop it.

On Sun, 28 Nov 2021, 22:52 MichaIng, @.***> wrote:

Ah okay, that explains it, I guess 🙂. However, those are not content of and not created via libraspberrypi0 package maintainer script, so would be good to have a build which uses the .0 ones directly.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/silvanmelchior/RPi_Cam_Web_Interface/issues/640#issuecomment-981167769, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDNQQS65GIJWR7MPKKYVQTUOKXDRANCNFSM5HVBUB7Q .

[roberttidey]

I have just done an install on a clean Bullseye (no userland development) in order to check the libraries.

After the normal apt-get update upgrade I checked the lib folder and the libraries were there with the links.

So I then did a git clone of the installer and ran it. There I did discover a problem in that it was not fully making the changes /boot/config.txt to enable the legacy camera stack. The start_x=1 and gpu_mem=256 lines were not being appended to the end as they should due to a permissions problem in the install script. I have now amended the method to add these lines.

After doing this and rebooting to allow the config changes to take effect raspimjpeg did start up and run OK.

I did not install anything extra like libraspberrypi0 during this.

So at the moment I think it was not a library problem but just a scripting error in the install.

I have refreshed the install on gitHub

[MichaIng]

I checked the lib folder and the libraries were there with the links.

I just checked the Raspberry Pi OS Bullseye image, and you are right the links are there. This is quite a problem as the links are not added by the package and not even by pi-gen, which means they were created manually for the RPi OS Bullseye images. So no one who uses pi-gen to create own images, upgrades from Buster to Bullseye or even used Bullseye for a longer time and simply upgraded libraspberrypi0 some months ago will have those symlinks. But all packages which make use of these libraries and were compiled on the official Bullseye image require them.

This transition wasn't really thought through... I'll open a bug report at the RPi repo to suggest either adding the symlinks to the package itself of removing them from the RPi OS images to have consistency.

And I recommend hence to compile the binary again, removing the symlinks manually first, so that those are assured to work, regardless how users installed the libraries and how they got or generated the image.

[MichaIng]

FYI: https://github.com/raspberrypi/userland/issues/715 When the symlinks are added to the package, all is fine, as the .0 suffixes are as well specific to the package while the upstream blobs do not contain them: https://github.com/raspberrypi/firmware/tree/master/hardfp/opt/vc/lib

[MichaIng]

@roberttidey Maybe the presence of the symlinks is not an issue: https://github.com/raspberrypi/userland/issues/715#issuecomment-981665724

But actually that contradicts the fact that the current binaries are indeed linked against paths without the .0 ending. Can you verify via ldd whether your newly compiled binaries are now linked against .0 libraries or not? Not sure whether linkers are supposed to resolve/follow symlinks or not, or whether different toolchains lead to different results 🤔.

[roberttidey]

ldd shows it is using the links that exist.

/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so => /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so (0x76f4b000) libmmal_core.so => /lib/arm-linux-gnueabihf/libmmal_core.so (0x76f1a000) libmmal_util.so => /lib/arm-linux-gnueabihf/libmmal_util.so (0x76efb000) libmmal_vc_client.so => /lib/arm-linux-gnueabihf/libmmal_vc_client.so (0x76edd000) libbcm_host.so => /lib/arm-linux-gnueabihf/libbcm_host.so (0x76eb7000) libvcsm.so => /lib/arm-linux-gnueabihf/libvcsm.so (0x76e9c000) libvchiq_arm.so => /lib/arm-linux-gnueabihf/libvchiq_arm.so (0x76e85000) libvcos.so => /lib/arm-linux-gnueabihf/libvcos.so (0x76e69000) libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x76e3d000) libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0x76e29000) librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0x76e11000) libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76cbd000) /lib/ld-linux-armhf.so.3 (0x76f60000) But with the changes I made to the install.sh raspimjpeg is running fine and the software is operating well on a machine with just bullseye + regular install method.

Note that this raspimjpeg was built on Bullseye but back on Nov 12. My next step will be to recompile on my latest Bullseye to see if that makes any difference to the ldd results. I didn't want to put / compile userland on before running the basic tests to see if raspimjpeg works as intended.

The libraspberrypi0 link is very interesting. It would be good to get any explicit additional steps to take if required to get the linkage direct.

[MichaIng]

Just to verify, when you remove the symlink, the binary fails, right?

rm /lib/arm-linux-gnueabihf/libmmal_core.so
raspimjpeg
# restore
ln -s /lib/arm-linux-gnueabihf/libmmal_core.so.0 /lib/arm-linux-gnueabihf/libmmal_core.so

[roberttidey]

Yes. It fails with link removed and is OK when restored.

After a compile with updates Bullseye it show the raspimjpeg is still using the links as before.

A dpkg-query -l shows that all libraspberrypi0 packages including dev are present in the Bullseye install.

As I build all of userland to build the raspimjpeg that may be why it picks up the local lib references as they get built locally.

[MichaIng]

Btw, which sources for raspimjpeg are you using? It isn't from the archived userland repo, is it? Probably I can play with the build and see what I get.

[roberttidey]

Wiki https://elinux.org/RPi-Cam-Web-Interface

Section 1.5 gives link to the forked userland which builds raspimjpeg

Note that the software is now working OK under Bullseye using legacy camera support. If you are looking at porting to libCamera then that is quite an undertaking with a few barriers like support for vector motion detection. Check out posts by 6by9 around 2 Dec 2021 https://forums.raspberrypi.com/viewtopic.php?t=63276&start=5325

[MichaIng]

Thanks!

Note that the software is now working OK under Bullseye using legacy camera support.

So the links are now correctly pointing to *.0 libraries?

Great to see that there is some discussion around V4L2/libcamera migration. Currently, using legacy camera driver, this means full KMS vc4-kms-v3d display driver is not supported, but only fake KMS vc4-fkms-v3d (no non-GL legacy framebuffer driver) in combination with raspimjpeg, do I get this right?

[rudraforweb]

i just use legacy cam support in sudo raspi-config

[Yves911]

I understand that 64 bits BULLSEYE is not supported, no workaround ?

[MichaIng]

I understand that 64 bits BULLSEYE is not supported, no workaround ?

=>

i just use legacy cam support in sudo raspi-config

[roberttidey]

There is no work around for 64 bit currently. The raspberry libraries that are used for the legacy support are not compatible with 64 bit.

The only future prospect of 64 bit support is moving to libCamera for the underlying camera support but this currently lacks some of the key features that raspimjpeg uses on. Theoretically these could be emulated in software but this undermines one of the key benefits which is the ability to be run efficiently even on modest platforms like the Pi zero.