Incompatibility with libcamera 0.1.0 and Raspberry Pi 5 #2581
Comments
aler9
changed the title
|
Hello, the server is compatible with only a version of libcamera at the time, and the current compatible version is 0.0.5. It seems like Raspberry Pi maintainers are starting to unroll 0.1.0 on some OS-hardware combinations, but not on everyone. Anyway, the majority of OSs currently run 0.0.5, so we can't perform the upgrade right now, but i'll keep this issue open in order to monitor the situation. |
|
I reported a bump in version a while ago that you thankfully were able to resolve quickly. I cannot remember how I previously got the version. Just in case I have somehow provided an incorrect version this time I thought I should provide info on how it was obtained. libcamera-hello --versionReports libcamera-apps build: 7e4d3d71867f 22-08-2023 (10:57:38)
libcamera build: v0.1.0+52-a858d20bThanks for your help. |
|
We could quickly solve this issue too, but the problem is that i just checked the latest libcamera version on my Raspberry Pi, and it's still 0.0.5, so a full switch to 0.1.0 would cause problems to most users. |
|
I will use docker in meantime. |
|
Hi, Extract of error logs : |
|
Unfortunately libcamera version is still 0.0.5 on Raspberry Bullseye. If you need a server version that is compatible with libcamera 0.1.0, compile it from source by following instructions in the README, or use the Dockerized version, which is independent from libcamera. |
|
I have fix the issue with the following code in camera.cpp line 192: |
|
Bookworm is the latest Raspberry distro. That may explain the issue. |
|
In 1.2.1 I had to create library links in bookworm to get it running: |
|
new libcamera changes related to transform pushed to bookworm ;-) |
|
raspberry pi5 bookworm camera v3 docker |
|
After applying the @Topper69 patch to a Raspberry Pi 5 (Bookworm), the |
Have you tried to get the rasp5 camera videostream from gstreamer (to push the rtmp stream to mediamtx ) instead of the native raspberry pi camera support ? |
|
Now I was trying something like this: paths:
# example:
cam:
runOnInit: bash -c 'libcamera-vid -t 0 --codec yuv420 --width 1280 --height 720 --inline --listen -o - | ffmpeg -f rawvideo -pix_fmt yuv420p -s:v 1280x720 -i /dev/stdin -c:v libx264 -preset ultrafast -tune zerolatency -f rtsp rtsp://localhost:$RTSP_PORT/$MTX_PATH'
runOnInitRestart: yesIt works, but I observe 2-3 seconds delay and frequent freezes... Do you think switching to GStreamer would improve performance? EDIT: I tried using gstreamer and it's worse than using ffmpeg. Maybe I'm configuring something wrong? runOnInit: gst-launch-1.0 -v libcamerasrc ! "video/x-raw,width=1280,height=720,framerate=2/1" ! videoconvert ! x264enc speed-preset=ultrafast tune=zerolatency byte-stream=true bitrate=3000 threads=2 ! rtspclientsink location=rtsp://localhost:$RTSP_PORT/$MTX_PATH |
Worse for the delay ? |
Yes, for the delay and freezes |
Strange. try to tweak your gstreamer command. Take some inspiration from this one : |
Thanks for reporting this news since it changes a lot of things. Performing a linear bump of libcamera is not enough anymore and a little reasoning is needed before improving the server in order to deal with the issue. There are two separate problems, a technical one and a legal one. The technical problem can be solved by embedding a software encoder into the server and using it as failback. Raspberry Pi employees wrote that they recommend performing software encoding on the new Pi, even though it consumes at least an entire core. Let's do like they say, even though it sounds particularly inadequate in the era of 8k videos. Unfortunately embedding an H264 software encoder has legal implications, since H264 is covered by patents. Hardware encoders don't have this problem since the legal responsibility is on the hardware manufacturers, and that is why, for instance, Chrome supports H265 decoding if and only if there's an available hardware decoder, and the same applies to MediaMTX in case of H264 encoding. My idea is to change the video codec of the RPI camera from H264 to AV1, which is royalty free, and embed an AV1 software encoder into the server. AV1 is supported by most browsers and by a relevant fraction of mobile devices, although the compatibility level is not the same as the one of H264. I can't imagine any other way. |
aler9
changed the title
I would suggest to maintain the H264 option for backward compatibility with older devices and add option for AV1 for the newer devices. |
Hello, Just my two cents. With the Lite version of Bookworm, the video encoders are not included. You either have to use the full desktop version of rasbian bookworm, or compile rpicam-aps to get the h264 encoders. Reference: https://forums.raspberrypi.com/viewtopic.php?t=361268 |
|
@masipcat, I tried your solution and it works for my Raspberry Pi 5 (Raspberry Pi OS (64-bit)). It takes up to 5 seconds to start the stream, then it streams with a subsecond delay to my laptop over wifi. It even works for two cameras. My script with tiny improvements: |
|
If I run Before I had
as per docs I have no |
I met this problem too. |
|
i get the same issue on pi5 with docker image, ERR [path cam] [RPI Camera source] camera_create(): selected camera is not available |
|
The current incompatibility issue with libcamera0.1.0 (and 0.2.0 for that matter) also causes problems on other systems if you're trying to use Picamera2 on the current Raspberry Pi OS (Bookworm). I was testing a dual setup with MediaMTX for streaming and Picamera2 for taking still images with a Raspberry Pi Zero 2 running Bookworm but I'm putting this on hold for now. |
|
mine is Raspberry pi OS bootworm 64bit, application is openCV and I've tried to do : sudo modprobe bcm2835-v4l2 although I can see /dev/video0 libcamera-hello --list-cameras it shows: import cv2
from picamera.array import PiRGBArray
from picamera import PiCamera
import time
# Initialize the camera
camera = PiCamera()
# Set camera resolution (optional)
camera.resolution = (640, 480)
# Set camera framerate (optional)
camera.framerate = 32
# Initialize the video stream
rawCapture = PiRGBArray(camera, size=(640, 480))
# Allow the camera to warm up
time.sleep(0.1)
# Capture frames from the camera
for frame in camera.capture_continuous(rawCapture, format="bgr", use_video_port=True):
# Grab the raw NumPy array representing the image
image = frame.array
# Perform image processing with OpenCV (e.g., display the image)
cv2.imshow("Frame", image)
# Clear the stream in preparation for the next frame
rawCapture.truncate(0)
# Check for key press to exit the loop
key = cv2.waitKey(1) & 0xFF
if key == ord("q"):
break
# Release the camera resources
cv2.destroyAllWindows()
|
I was able to compile against libcamera 0.2.0 (part of current RasbperryPi OS, Bookworm) by removing these lines. It there an estimate on how long mediamtx will be dependent on |
|
Libcamera 0.3.0 has been pushed to bookworm and removed transform altogether. In order to compile from source, you need to use the new orientation enumeration. Replace the lines by @Topper69 with: conf->orientation = Orientation::Rotate0;
if (params->h_flip) {
conf->orientation = Orientation::Rotate0Mirror;
}
if (params->v_flip) {
conf->orientation = Orientation::Rotate180Mirror;
}
if (params->v_flip && params->h_flip) {
conf->orientation = Orientation::Rotate180;
}And replace |
|
Regarding the encoder, would it be possible to implement it in the same way as |
|
omg , this worked for me https://gektor650.medium.com/comparing-video-stream-latencies-raspberry-pi-5-camera-v3-a8d5dad2f67b |
This allows to use the RPI camera on the Raspberry Pi 5 too.
This allows to use the RPI camera on the Raspberry Pi 5 too.
|
MediaMTX now supports serving the Raspberry Pi Camera feed on both Raspberry Pi OS Bookworm and Bullseye (because dependencies have been embedded inside the server) and on the Raspberry Pi 5 (because a H264 software encoder was added as failback). |
|
This issue is mentioned in release v1.9.0 🚀 |
Which version are you using?
v1.2.0
Which operating system are you using?
Describe the issue
Description
mediamtx fails to work after
apt-get upgradeLibcamera: v0.1.0+52-a858d20b
Describe how to replicate the issue
sudo apt-get update && sudo apt-get upgrade-y
Did you attach the server logs?
yes
Did you attach a network dump?
no
The text was updated successfully, but these errors were encountered: