[BUG] Start to experience high rate of frame dropping after latest update (v0.3.1+50-69a894c4)

[EwingKang]

Describe the bug Start to experience high rate of frame dropping after latest update (v0.3.1+50-69a894c4)

Bug report bugreport0.txt bugreport1.txt

Additional context I'm using rpicam-vid to capture 2 cameras at the same time on a RPI5. I needed these two cameras to capture video in sync. Doing it by calling two instance of rpicam-vid does the job pretty well before without framedrop.

rpicam-vid --camera 0 $VIDOPT -o ${HOSTNAME}_cam0_${SUFFIX1}_${SUFFIX2} &> log_${HOSTNAME}cam0_$SUFFIX1_$DATETIMEFULL.txt &
rpicam-vid --camera 1 $VIDOPT -o ${HOSTNAME}_cam1_${SUFFIX1}_${SUFFIX2} &> log_${HOSTNAME}cam1_$SUFFIX1_$DATETIMEFULL.txt

I'm doing it with a very save setting of 16401232@15 FPS on a IMX219. (Previously I have tested the setting up to 16401232@25 fps without any issue) At this setting, the total CPU usage is < 65% After the update v0.3.1+50-69a894c4 random framedrop starts to appear quite frequently. The same 45 second, 15FPS video no longer gives a stable 668 frames, but varying between 668, 652, 659, 660, 663 frames. I dropped the framerate to as low as 5, and tested with different bitrate, still seeing varying framerate.

[naushir]

Can you post a clip of the captured video showing frame drops at 15fps that I can inspect please?

[EwingKang]

@naushir Thanks for your response. These are two videos comming from two RPIs. The left is the one with 660 frames, the right one is the 668 frames. I triggered capturing both rpi to within 10 ms accuracy. The cellphone screen is a count down timer. For 15 FPS, there should be 66 ms between each frame.

Here are 3 consecutive frames. Frame dropping occured between frame 2 and 3.

• 39.726
• 39.792
• 39.859
• The missing 8 frames (only stepping the right camera frames)
• "Catch-up", notice the timestamp difference

[naushir]

Would you be able to post the actual video files so I can have a look at all the frame timestamps please?

[EwingKang]

@naushir I can only provide the camera that has missing frames at this link Can't promise how long I can keep this link alive, though

[naushir]

From the video you linked, I only see a single frame glitch, this is at approx frame 600, where the system seems to stall for approx 600ms. Every other frame time is between 66.6 - 67ms apart as you would expect. This glitch produces a large set of frame drops, but I cannot see any frame drops in any of the preceding frames:

You can use this script to verify your results. Perhaps some other effect is causing what you are seeing?

[EwingKang]

I believe that your analysis matches what I saw with the SMplayer. At t+39.792, the cellphone screen is showing 04:01, however, at the next frame t+39.859, the cellphone screen is showing 03:43?. Since we're counting down, the difference is almost exactly 600 ms. I think SMplayer uses a constant 15 FPS (66 ms) to calculate and to the displayed t+ value.

This "frames skipping" behavior starts showing frequently after the said updates. Everything else is the same. And it does so on all 3 of my RPi-5s (1x8G RAM, 2x4GB RAM) I'll use the script to analyze other clips with missing frames to see if I can get any patterns tomorrow.

[naushir]

Are you saving to an sdcard or a faster medium? Wear on the sdcard may cause slowdowns like this when the system decides the flush the data into the card. Another thing to try would be to add force_turbo=1 to /boot/firmware/config.txt at the bottom of the file. This will ensure no clock throttling will happen when you are running.

[EwingKang]

@naushir It seems like the culprit is, indeed, the SD card degradation. I can no longer see the frame-dropping behavior after setting the destination to an external SSD drive. Due to physical space limitations, I'll probably have to use ramdisk (tmpfs). Thank you very much for the help! I'm perplexed by the coincidence of the event! All 3 Pis start showing such behavior at the same time. Maybe the update happens to make my Kingston SD card reach its degradation limit. ;(

• Original behavior

• By using ramdisk (tmpfs) as described here

P.S. It Seems like the ram-disk solution causes my CPU usage to become very high from the original 60% to >95%. I'll probably have to get an SSD Hat or something. Thanks for the help again.