fix(recording): keep the recorded display fps when finalizing a Studio recording

[richiemcilroy]

Exports of Studio recordings dropped every picture shorter than 1/average-fps, and their audio/video sync wandered by tens of milliseconds. Also in cap-v0.6.0.

Cause

Every fragmented Studio recording is finalized after Stop by RecoveryManager::remux_if_needed (apps/desktop-gpui/src/recording.rs, apps/cli/src/record.rs). That path rebuilds the recording's metadata in build_recovered_meta. It set the display track's fps from the finalized file's average frame rate (get_video_fps, avg_frame_rate), replacing the capture rate the recorder had written. A mostly static screen records few frames, so its average is far below the capture rate: 11 to 20 fps measured for 60 fps captures.

The decoders number frames on that rate (segment_video_timing → spawn_decoder(…, fps)). On an 11 fps grid, one step is 91 ms, so every picture on screen for less than that can be skipped. Moving content in a mostly static recording exports choppy, and editor playback does the same.

Fix

build_recovered_meta keeps the display fps from the recording's own metadata. Only when there is none (crash recovery with no metadata) does it use the stream's base frame rate (r_frame_rate, new get_video_base_fps), not its average. The camera track already kept the recorded fps.

Measured

Real devices on a MacBook Pro (built-in display and MacBook Pro Microphone). A stimulus shows a new marker picture 15 times a second and plays audio markers through the speakers; Cap's CLI records a 19 s Studio recording and exports it at 1920x1080, 30 fps. screen minus mic compares when each picture and each audio marker reach the export against when the stimulus presented and played them.

Build	Display fps in metadata	Pictures in the export	Screen minus mic
cap-v0.6.0 (2 runs)	13, 13	183, 183 of 210	+71.2, +65.6 ms
main (4 runs)	20, 11, 18, 18	209, 154, 209, 209 of 210	+4.2, +53.3, +32.6, +20.6 ms
main, with the metadata of the 11 fps run set to 120	120	210 of 210	+20.3 ms
This PR (2 runs)	60, 60	210, 210 of 210	+6.6, +8.9 ms

• studio_finalization_keeps_the_recorded_display_fps writes 120 fps into a recording's metadata, finalizes it and checks the 120 survives. It fails without the fix (30).
• Recordings already finalized keep their stored average; this fixes new recordings.

Confidence Score: 5/5

The PR appears safe to merge; the latest change fully addresses the previous finding.

Summary

Studio finalization keeps the recorded display frame rate and uses the stream’s base rate when no positive stored rate exists.

• Studio finalization keeps the display's recorded frame rate.

_{Reviews (3) · Last reviewed commit: "test(recording): drop a fixture comment ..." · Reviewed by Greptile}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
cap-status	Ready	Preview	Oct 17, 2026 11:21pm UTC

[capy-ai]

Capy found no issues.

[richiemcilroy]

@greptileai review

[capy-ai]

Capy found no issues.

[richiemcilroy]

Removed the helper comment in 0813d91. @greptileai review

[capy-ai]

Capy found no issues.