Libcamera-vid video skips, lags and flickers on 16MP IMX519 quad camera kit Raspberry Pi

Raspberry Pi Cameras
1

Hi everyone, I’m stuck with libcamera-vid recordings on the Arducam 16MP IMX519 Autofocus Synchronized Quad-Camera Kit (4x IMX519 cameras). The recorded file test.h264 skips and lags. It should be about 20 seconds long but it plays for much less. The picture flickers and isn’t smooth. I reproduced it with all 4 cameras together at 15 fps and also with just 1 camera at 60 fps, so I don’t think it’s simply a low fps issue.

Also, running ./install_pivariety_pkgs.sh -p imx519_low_speed_driver returns ‘Unsupported Package’. Has anyone run into this?

Two more questions: does the fps conversion also apply to 1-camera video, and is this only a VLC playback problem or do I have to convert every video this way?

2

Welcome! To help narrow this down, can you share a bit more about the setup? Specifically:

  • Which Raspberry Pi board and kernel version (uname -a)?
  • How did you install libcamera and libcamera-apps, and which install commands have you run so far?
  • What does your /boot/config.txt camera section currently look like?
  • Can you upload the arducam bug report and a short test clip?

That ‘Unsupported Package’ error is worth looking at too, but let’s capture the environment first.

3

Here’s the environment:

  • Raspberry Pi, kernel 6.1.21
  • Arducam 16MP IMX519 Autofocus Synchronized Quad-Camera Kit (4x IMX519)
  • Arducam Pivariety V4L2 driver, libcamera / libcamera-apps
  • Playback in VLC
  • Recording rates: 1 camera = 60fps, 2 cameras = 30fps, 4 cameras = 15fps

These are the install/record commands I ran:

wget -O install_pivariety_pkgs.sh https://github.com/ArduCAM/Arducam-Pivariety-V4L2-Driver/releases/download/install_script/install_pivariety_pkgs.sh
chmod +x install_pivariety_pkgs.sh
./install_pivariety_pkgs.sh -p libcamera
./install_pivariety_pkgs.sh -p libcamera_apps
./install_pivariety_pkgs.sh -p imx519_kernel_driver_low_speed
./install_pivariety_pkgs.sh -p imx519_low_speed_driver
sudo rpi-update c4617e0
libcamera-still -t 5000 -n -o test.jpg
libcamera-vid -t 10000 -o test.h264
ffmpeg -r 15 -i input_video.h264 -c:v copy -r 15 output_video.mp4

For /boot/config.txt I added dtoverlay=imx519 under [all]. I did not add the dtoverlay=camera-mux-4port,cam0-imx519,cam1-imx519,cam2-imx519,cam3-imx519 line.

The imx519_low_speed_driver package gives ‘Unsupported Package’. Here is a screenshot of the recording output: image.png

arducam-bug-report.txt and test.h264 are here: arducam bugs - Google Drive

4

Thanks, that’s helpful. A couple of things jump out. First, try recording with explicit width and height, because some IMX519 modes don’t pick a sensible default and that can cause exactly the flicker/skip you’re describing:

libcamera-vid -t 20000 --width 1920 --height 1080 -o test.h264

Also, since you’re on the synchronized quad-cam kit, can you confirm whether you’re using the 4-port mux overlay in config.txt or just the single imx519 overlay? You mentioned dtoverlay=imx519 under [all] without the camera-mux-4port line.

5

Quick update: specifying the width and height in the libcamera-vid command fixed the capture issue. I also added dtoverlay=imx519 under [all] without the camera-mux-4port line and it seems to work. I updated the kernel to 6.1.21 (firmware commit c4617e02da233ff70940223a06e568a193fc446d). Capture looks better now, but VLC playback is still skipping. I’m planning to try the ffmpeg conversion to fix VLC playback.

6

Right, the playback issue is likely a frame-rate mismatch. A video recorded at 15 fps for 20 seconds contains 300 frames. If it’s played at 15 fps it lasts 20 seconds, but if VLC assumes 30 fps or 60 fps, that same 300-frame file plays back in 10 or 5 seconds and looks like it skips. Raw .h264 streams often don’t carry a reliable fps value, so VLC has to guess and can get it wrong.

7

That makes sense. I have this ffmpeg line but want to make sure I use it correctly:

ffmpeg -r 15 -i input_video.h264 -c:v copy -r 15 output_video.mp4

Can you walk me through what each part does?

8

Sure. Assuming the original video was recorded at 1920x1080, run that command in the terminal to create a new file:

ffmpeg -r 15 -i input_video.h264 -c:v copy -r 15 output_video.mp4
  • input_video.h264 is the original file, and output_video.mp4 is the new file.
  • -r 15 sets both the input and output frame rate to 15 fps, matching the original recording.
  • -c:v copy copies the video stream without re-encoding, which is faster and keeps the original quality.
  • If the original was recorded at a different resolution, adjust the -vf scale option accordingly to match the desired resolution.

Try that on one of the 15 fps 4-camera clips and see if VLC plays it correctly.

9

Thanks, that worked better for the 15 fps clip. Two follow-ups: does this fps conversion also apply to the 1-camera 60 fps videos? And is this a VLC-only problem, or will I have to convert every recording this way every time?

10

Good to hear. The current conclusion is that the playback problem is caused by the player using a different frame rate than the recording. For the 15 fps 4-camera footage, the ffmpeg remux at -r 15 is the workaround. For 1-camera 60 fps footage, the same principle should apply, but I’d test a short 60 fps clip to confirm it needs the same treatment. On the VLC question, it’s not strictly VLC-only—any player needs to know the correct fps, and raw .h264 files often don’t store that reliably, so VLC guesses wrong. Whether you must convert every time depends on how the capture writes fps metadata. Right now, remuxing the raw .h264 recordings with ffmpeg is the workaround. The ‘Unsupported Package’ error for imx519_low_speed_driver is still open as well, so we can revisit that after you test the 60 fps clip.