CameraX delivered 24 fps, but our encoder received about 18

[getguardianeye]

While debugging Guardian Eye WebCamera on Android, we found that frame loss was happening twice. CameraX could deliver 24 frames per second to the app, but the MediaCodec input received only about 18.

Our CameraX analysis pipeline uses ImageAnalysis.STRATEGY_KEEP_ONLY_LATEST. If analysis falls behind, CameraX keeps the newest image and discards an older one. That makes the arrival times less regular even when the camera was requested to run at 30 fps.

The second loss came from our own VideoFrameRateGate, which limits how many frames are submitted to the encoder. We reproduced the problem with timestamps from a 30 fps source and removed every fifth frame. The gate therefore received 24 frames per second. Its old deadline calculation moved the next deadline forward after a late frame and discarded the unused part of the previous interval. With the gate also set to 24 fps, it rejected about six more frames.

The deadline now advances from its existing schedule, with any saved time limited to one frame interval:

nextDuePtsUs = maxOf(due + intervalUs, ptsUs)

Regular input is still capped at the configured rate. When capture is slower than that cap, each available frame can pass. After a long pause, the bound prevents the encoder from receiving a catch-up burst.

The regression tests cover 60 fps input capped at 30 and 15 fps, irregular 30 fps input with missing frames, a long capture gap, and a slowdown from 30 to 5 fps followed by recovery to 30.

This change stops our encoder gate from adding another frame-rate reduction after CameraX has already dropped a frame.

If you see a large gap between CameraX analysis FPS and encoder input FPS in WebCamera, please include the phone model, resolution, requested frame rate, and whether the numbers change after rotating the phone.

Guardian Eye WebCamera:

Google Play: https://play.google.com/store/apps/details?id=eye.guardian.webcam