libcamera-vid variability in frames captured with no reported frame drops

[dustinkerstein]

When running the following command: libcamera-vid --framerate 10 --width 4096 --height 3040 -t 24000 --awbgains 1,1 --shutter 100000 --denoise cdn_fast --codec yuv420 --save-pts timestamps.txt -o /dev/shm/camera.yuv The resulting output file sometimes contains 227 frames, and sometimes 231. Strangely I've never seen any other outcomes across ~10 attempts. I am calculating the number of frames by taking the byte size of the file and dividing by 18677760 (4096x3040x3/2):

4314562560 total bytes / 18677760 bytes per frame = 231 frames 4239851520 total bytes / 18677760 bytes per frame = 227 frames

Based on the 10 second timeout, I would expect to see 240 frames (10fps * 24 seconds), but that's potentially a different issue, or just not guaranteed with a time-based timeout. On a slight tangent, it would be nice to be able to provide a num-buffers parameter to capture an exact number of frames (important in my use-case). See here for a similar feature request for libcamerasrc.

Back to the variable frame output. You can find both timestamp files here: 227.txt, 231.txt

In the 227 timestamp file, there is a 4 frame gap between 1100 and 1600. However, in both cases libcamera-vid never logs a frame drop (ie. "Dropping unmatched input"). See the debug log for a 231 frame capture here - 231_Frame_Log.txt and for the 227 capture here - 227_Frame_Log.txt

Are you able to replicate this behavior? Let me know if there's anything else I can get.

I am testing with an Arducam Mini IMX477 module + Compute Module 4 + Official IO Board + Bullseye Lite 64bit + 5.10.63-v8+ Kernel running headless over ssh. Full system info here - https://pastebin.com/654vBepL

$ libcamera-hello --version
libcamera-apps build: 2a38ae93f143 21-10-2021 (14:53:29)
libcamera build: v0.0.0+3156-f4070274
$ vcgencmd version
Oct 29 2021 10:47:33
Copyright (c) 2012 Broadcom
version b8a114e5a9877e91ca8f26d1a5ce904b2ad3cf13 (clean) (release) (start)

[dustinkerstein]

Ok interesting. I'll play around with that later today. On a related note, do you happen to know of any way to get the Pi to allocate CMA beyond the 1GB barrier? I've heard it might break some peripherals, but that might be ok for me depending on what it breaks. While a bit ugly, it's temping to just have 300 buffers in CMA... Thanks for your help.

[naushir]

You can use the vc4-kms-v3d (Bullseye) overlay to change cma size. Try dtoverlay -h vc4-kms-v3d for more info. Note, that neither the ISP nor the Unicam hardware can address that high memory, so it would be pointless.

[naushir]

I'll close this down as the original issue should be resolved.