[BUG] libcamera-vid piped into cVLC runs then crashes #238
Comments
|
Issue #236 shares the same warning/error: |
|
I started searching the code and found the comment at line 66 in qt_preview.cpp And then I modified my command line to include the option of "-n " for no preview window. That's seems to have made a significant impact: the server has been running for over 30 minutes now and is on-going with 4 connections. Works-for-me = omit the preview window Issue #236 ought to try the same and report. |
Yes, I have reproduced this on my build as well. Will investigate now and see what could be the cause. |
|
We have identified the cause of this problem, and a fix has been submitted for review/merge here. Hopefully this should be merged very soon. |
…nput stream The ISP input stream currently only allocates a single slot in the V4L2VideoDevice cache as it follows the number of buffers allocated for use. However, this is wrong as the ISP input stream imports buffers from Unicam image stream. As a consequence of this, only one cache slot was used during runtime for the ISP input stream, and if multiple buffers were to be queued simultaneously, the queue operation would return a failure. Fix this by passing the same number of RAW buffers available from the Unicam image stream. Additionally, double this count in the cases where buffers could be allocated externally from the application. Bug: raspberrypi/rpicam-apps#236 Bug: raspberrypi/rpicam-apps#238 Bug: raspberrypi/rpicam-apps#240 Signed-off-by: Naushir Patuck <naush@raspberrypi.com> Reviewed-by: David Plowman <david.plowman@raspberrypi.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
The fixes for this issue have now been merged. You can get the latest libraries by doing: I'll close this issue down now, please re-open if you still have problems. |
|
Thank you, the command line quoted in the opening of this issue and from the documentation works now. However, I have not performed any serious testing, but will share with something in a new bug after I have marshaled all the information and run some debug capture logs for you. The problems are the "WARN" lines. This was the 3rd run and they seem to come on after 3-10 minutes of running without displaying WARN messages. In the session below, I had an emacs on the desktop and an emacs through an ssh connection running; the CPU started in the 45% slowly inching its way up to 52%. I was not active elsewhere on the unit, so the slow increment climb should be attributable only to this process. Definitely need a more careful test and investigation. Also, I was noticing a lot of dropped frames. The RPiZero2W is connected to a switch which my Windows workstation is connected to, all within several feet of one another. I could be having network issues, next time I'll try to run a separate VLC on the RPi2W desktop to capture statistics which would represent no-network conditions since both processes are on the same unit. Here's one of the VLC statistics from an instance run on my Windows workstation: |
|
Those warnings indicate probable frame drops. There could be many causes of this, but there is one in particular that we have been looking at very recently. It turns out that the info text updates on the preview window seem to be very expensive. It might be worth trying to disable those updates with the |
On a Pi Zero 2 W with 64-bit Bullseye and Raspberry Pi HQ camera.
Running "libcamera-vid" and piping into command line VLC. for RTSP server.
Here are the libcamera packages installed:
Following instructions at https://www.raspberrypi.com/documentation/accessories/camera.html#libcamera-and-libcamera-apps
which states to run a server, use this command line:
Instead, I used this modified version which includes the IP address of the Pi server running this command:
The server runs for about 3 minutes and then crashes, sometimes it crashes sooner
The last lines in the log are:
Also, there are these messages:
Attached is a script session (test_script1_Jan_29_2022_log.txt) which contains a prefix consisting of "[time stamp] [numberical sequence number]"
test_script1_Jan_29_2022_log.txt
Attached as (bug-report_20220129_104241.zip) is an attempt using:
bug-report_20220129_104241.zip
which failed and logged as Issue #237.
The text was updated successfully, but these errors were encountered: