[BUG] Long recordings progressively drop video FPS to a few FPS while audio remains continuous

[airobot-bot]

Bug Report

Description

During long recordings, FadCam progressively drops the actual video frame rate over time.

The recording is configured as 30fps, and it starts close to 30fps, but the real video FPS gradually decreases during the session. Near the end of a 4–5 hour recording, the video may only contain around 3–5fps.

The audio stream remains continuous and normal. The app does not crash or stop recording. The final file is created successfully, but the video frame timestamps become increasingly sparse.

This looks like a long-running video pipeline issue, possibly related to camera frame delivery, GL rendering, MediaCodec backpressure, muxer/disk I/O, thermal throttling, or Android/ColorOS background scheduling.

Steps to Reproduce

1. Open FadCam on a OnePlus 9R.

2. Configure recording roughly as:

   • Codec: H.264 / AVC
   • Resolution: 1280x720
   • Frame rate: 30fps
   • Bitrate: around 8Mbps Auto or similar

3. Disable stream/server features.

4. Start a long recording session, around 2–5 hours.

5. Let the recording complete normally.

6. Analyze the real video frame timestamps with ffprobe, instead of only checking the nominal FPS shown by media players.

Example command:

ffprobe -v error \
  -select_streams v:0 \
  -show_frames \
  -show_entries frame=best_effort_timestamp_time \
  -of csv=p=0 \
  input.mp4 > frames.csv

Then calculate the actual FPS per 10-minute window from the frame timestamps.

Expected Behavior

The actual video frame timestamps should remain close to the configured 30fps during the full long recording session, or at least degrade gracefully with a visible warning.

Audio and video should both remain temporally stable. The video stream should not silently degrade to only a few frames per second while the recording continues.

Actual Behavior

The recording starts near 30fps, but the actual video FPS gradually drops over time.

Sample 1:

File: Stream_20260629_072501.mp4
File size: 3.4GB
Resolution: 1280x720
Codec: H.264
Video duration: about 03:51:34
Audio duration: about 03:51:41
Average real video FPS: about 15.82fps
Max video frame interval: 3.56s at about 03:50:48
Audio packets are continuous; max audio timestamp gap is about 0.006s, with no >50ms gaps

Actual video FPS by 10-minute window:

00-10 min: 29.14fps
10-20 min: 27.90fps
20-30 min: 26.61fps
50-60 min: 22.73fps
1h40-1h50: 16.82fps
2h40-2h50: 9.90fps
3h20-3h30: 5.56fps
3h40-3h50: 4.40fps

First noticeable video timestamp gaps:

>120ms frame gap: 00:00:38
>200ms frame gap: 00:13:51
>500ms frame gap: 00:47:50
>1s frame gap: 01:46:42

Sample 2:

File: FadCam_20260623_051032.mp4
File size: 3.9GB
Resolution: 1280x720
Codec: H.264
Video duration: about 05:05:28
Average real video FPS: about 13.04fps
Max video frame interval: 4.08s at about 05:02:44

Actual video FPS by 10-minute window:

00-10 min: 29.15fps
10-20 min: 27.83fps
20-30 min: 26.49fps
50-60 min: 22.64fps
1h50-2h: 15.38fps
Around 3h: 7.89fps
Around 4h: 5.08fps
Around 5h: 3.01fps

The important point is that the nominal media property may still show 30fps, but the actual frame timestamps show progressive FPS degradation.

Screenshots

No UI screenshot is available because this is not a visible UI error during recording.

The issue is visible after analyzing the recorded file’s video frame timestamps. I can provide FPS analysis logs or sample timestamp data if needed.

Environment

• Device: OnePlus 9R

• OS: ColorOS 14.0, Android 14.0

• App Version: FadCam v4.0.0-beta9 build 37

• Recording Settings:

  • Codec: H.264 / AVC
  • Resolution: 1280x720
  • Frame rate: 30fps
  • Bitrate: around 8Mbps Auto or similar
  • Stream/server: disabled during testing

• Use Case: Long-duration recording sessions, usually 2–5 hours

Additional Context

Things already checked or ruled out:

• The issue is not caused by LosslessCut or cutting/exporting. The original raw recording already has sparse video frame timestamps.
• The audio stream does not appear to be failing. Audio packets remain continuous.
• The issue is not caused only by the remote stream/server feature. It still happens after disabling stream/server.
• The issue is not caused only by fast charging. It also happens with slow charging.
• The app is not simply being killed by the system. The recording continues and completes, but the actual video FPS progressively degrades.
• Locking the app in recent tasks may prevent it from stopping, but it does not guarantee stable video FPS.

Possible areas to investigate:

• Long-running GL recording pipeline degradation
• Camera frame delivery slowdown under ColorOS / Android 14
• MediaCodec encoder backpressure
• Encoder drain loop not keeping up over time
• Muxer or disk I/O slowdown with large single files
• Progressive frame coalescing / dropping in the render loop
• Thermal throttling causing the video path to fall behind
• Overlay/watermark/rendering path increasing load during long recordings
• Need for safer segment rollover or full encoder/pipeline restart during long recordings

Helpful diagnostics could include logging these metrics every 60 seconds during recording:

camera frames received
SurfaceTexture onFrameAvailable count
GL render frames
encoder input frames
encoder output frames
muxer written video samples
dropped/coalesced frames
render runnable queue delay
renderFrame duration avg/p95/max
drainEncoder duration avg/p95/max
muxer write duration avg/p95/max
actual video FPS in the last 60 seconds
thermal status / battery temperature
memory usage / GC events
current segment duration and file size

Possible mitigation ideas:

1. Add a “long recording safe mode” that disables unnecessary GL/watermark/overlay processing.
2. Allow disabling all overlays and preview work for long recordings.
3. Add automatic recording segmentation every 15–30 minutes.
4. Optionally fully restart the encoder / muxer / GL pipeline between segments.
5. Show a warning if actual video FPS over the last 60 seconds drops far below the configured FPS.
6. Lower bitrate automatically if encoder or muxer backpressure is detected.
7. Add thermal-aware degradation: reduce bitrate/FPS or warn the user when the device gets hot.
8. Ensure Camera2 is requesting a fixed target FPS range, for example 30/30 where supported.
9. Track and report dropped/coalesced frames in logs.

Priority

• Low
• Medium
• High