Add support for Bookworm with new `rpicam-mjpeg` backend

[dylan-lom]

The rpicam-mjpeg program is based off of the rpicam-apps project. It is designed as a replacement for the RaspiMJPEG program, which cannot be used on Bookworm due to the removal of MMAL APIs.

The project is still a WIP, with some more major bugs/issues highlighted in the Github issues, however it is functional as a proof of concept/starting point for switching to libcamera, supporting the preview stream, still image and motion detection functions.

To use the new program, run the ./bin/install-rpicam-mjpeg.sh script, which will

• Install rpicam-mjpeg to the system
• Create a symlink ./bin/raspimjpeg pointing to the rpicam-mjpeg program

Now the ./install.sh script can be run to install the web interface itself, and it will run rpicam-mjpeg by default (ie. when using start automatically, or ./start.sh).

The public source for rpicam-mjpeg is located: https://github.com/Windermere-Technology/rpicam-mjpeg

The project was completed as a part of university project, as discussed in #688, with contributions from @Yucheng-Yan, @ning-bao, @Pzhang768, @SheXinLim, @ching-cheng-lu, @Dinnicus, @Baiken1412, and mentorship from @wallarug 😊

[MichaIng]

Do you think rpicam-mjpeg has a future, since it did not receive any commit in 9 months, seems to be not compatible with latest libcamera and seems to be not popular. I am thinking about whether to keep the RPi Cam Web Interface in our software portfolio trying to get it running with rpicam-mjpeg, or whether to drop it all together, as there are no (other) efforts to get it working with libcamera. The dependency on gpac is another issue.

[dylan-lom]

Do you think rpicam-mjpeg has a future, since it did not receive any commit in 9 months, seems to be not compatible with latest libcamera and seems to be not popular.

This was done as a university project sponsored by @wallarug, at the completion of the project all of the hardware was returned so unless someone from the community wants to maintain the project it's unlikely.

as there are no (other) efforts to get it working with libcamera

If you haven't looked into it yet, I'd suggest you try the RaspyCam program instead of rpicam-mjpeg, which was another groups attempt at the same project. It seems to have attracted a bit more attention from the community and might work better?

[MichaIng]

If you haven't looked into it yet, I'd suggest you try the RaspyCam program instead of rpicam-mjpeg, which was another groups attempt at the same project. It seems to have attracted a bit more attention from the community and might work better?

Thanks, looks slightly more active, but last commit also from January. Installer is outdated, but I would theoretically need raspimjpeg (replacement) only, doing RPi Cam Web Interface integration/installation with own scripting anyway. I see it is based on picamera2, which is still in beta, but has solid development.

However, gpac is the other issue. Debian removed it intentionally, due to an ongoing high number of security issues. I guess MP4Box could be relatively easily replaced with ffmpeg. Do you know whether anyone had a look into this?

[roberttidey]

In the original raspimjpeg the conversion from h264 to mp4 is done by MP4Box, but the command used is based on running a separate command using the template contained in the config parameter MP4Box_ cmd.

It should be possible to change that configuration so that ffmpeg is used for conversions instead of MP4Box by recasting that config without changing anything in the original raspimjpeg binary.

I am not surre whether libCamera based versions invoke the conversion in the same way and respect the config parameter

[MichaIng]

Oh right, I saw the command being executed directly here: https://github.com/silvanmelchior/RPi_Cam_Web_Interface/blob/master/www/macros/startstopX.sh#L31 But that is an example script only.

rpicam-mjpeg seems to not use MP4Box at all, but FFmpeg. Makes sense that the raspimjpeg config is mostly or fully ignored by the libcamera-based replacements.

[wallarug]

If you haven't looked into it yet, I'd suggest you try the RaspyCam program instead of rpicam-mjpeg, which was another groups attempt at the same project. It seems to have attracted a bit more attention from the community and might work better?

Thanks, looks slightly more active, but last commit also from January. Installer is outdated, but I would theoretically need raspimjpeg (replacement) only, doing RPi Cam Web Interface integration/installation with own scripting anyway. I see it is based on picamera2, which is still in beta, but has solid development.

However, gpac is the other issue. Debian removed it intentionally, due to an ongoing high number of security issues. I guess MP4Box could be relatively easily replaced with ffmpeg. Do you know whether anyone had a look into this?

Andrei @goombado could update the installer for you. Feel free to tag him for more details.

[MichaIng]

As said, we'd not need the installer anyway, but implement this ourselves. That it is outdated was more a hint about the project status in general. Outdated installer means less random user (able to) tests, less feedback, less chance for a community to grow etc.

Basically, at this stage, I do not see any of the projects at status that we would need for it to make sense. For individuals who are willing to tinker for a personal RPi project this may work, but I am deciding whether to keep RPi Cam Web Interface as a software option to distribute with our Linux distro or not. And if neither the parent project, nor the camera backend are actively maintained, it would take too much of my time without sustainable future in sight. With motionEye, I am (co-)maintaining already a similar project, and there I am not able to invest as much time as I would like to, or as the project would deserve. No chance I am going to burden myself with another one 😅.

But thanks for the insights guys. I really hope that at some point a libcamera-compatible camera web UI project manages to gain an active developer/maintainer team and user base/community. With RPi dropping support for its legacy camera module interface, and switching to libcamera which is not plain V4L2-compatible, a lot of projects were abandoned, or lost support for RPi camera modules. With motionEye, the problem similarly is that motion itself does not support libcamera either. A workaround is libcamerify, but it has its limitations as well. Currently, for RPi users without sufficient Linux experience, willing to tinker with the software, there is no way to get a webcam stream with some interface up quick and easy, which really is a gap in the ecosystem.

[wallarug]

As said, we'd not need the installer anyway, but implement this ourselves. That it is outdated was more a hint about the project status in general. Outdated installer means less random user (able to) tests, less feedback, less chance for a community to grow etc.

Basically, at this stage, I do not see any of the projects at status that we would need for it to make sense. For individuals who are willing to tinker for a personal RPi project this may work, but I am deciding whether to keep RPi Cam Web Interface as a software option to distribute with our Linux distro or not. And if neither the parent project, nor the camera backend are actively maintained, it would take too much of my time without sustainable future in sight. With motionEye, I am (co-)maintaining already a similar project, and there I am not able to invest as much time as I would like to, or as the project would deserve. No chance I am going to burden myself with another one 😅.

But thanks for the insights guys. I really hope that at some point a libcamera-compatible camera web UI project manages to gain an active developer/maintainer team and user base/community. With RPi dropping support for its legacy camera module interface, and switching to libcamera which is not plain V4L2-compatible, a lot of projects were abandoned, or lost support for RPi camera modules. With motionEye, the problem similarly is that motion itself does not support libcamera either. A workaround is libcamerify, but it has its limitations as well. Currently, for RPi users without sufficient Linux experience, willing to tinker with the software, there is no way to get a webcam stream with some interface up quick and easy, which really is a gap in the ecosystem.

Hey @MichaIng - completely get that. The raspimjpeg is about to become more active as I am planning on using it in our closed source camera software / replacement of RPI Cam Web Interface. Andrei works for me now (I hired him after the university project).

But happy to chat more offline if you need any assistance or advice around that. Just send me an email: [email protected]

[MichaIng]

Sounds good. I am keeping an eye on it.