Studio Mode export stuck at "Rendering video (0/X frames)" on macOS — never progresses

[webjuice1]

Description
When attempting to export or upload a longer recording (~36 minutes, 65,328 frames) via Studio Mode on Cap Desktop, the rendering step gets permanently stuck at "Rendering video (0/65328 frames)" and never processes a single frame. The progress bar stays at 0%. Only option is to cancel.
Short recordings (5-10 seconds) in Instant Mode work fine — they record, upload, and play back correctly. The issue is specific to longer recordings going through the Studio Mode rendering pipeline.
v0.4.71 release notes mention "Fixed an issue where frames were stuck at 0, and progress at 0% on specific devices" but the issue persists on this device.
Reproduction

Record a long screen recording (~30+ minutes) in Studio Mode
Stop recording
Attempt to export or upload
"Preparing..." dialog appears with "Rendering video (0/65328 frames)"
Progress never advances past 0 frames
Must cancel manually

Additional Context

Cap version: 0.4.71 (latest as of March 2026)
Operating system: macOS (Apple Silicon MacBook Pro)
Display: DELL S3221QS (5120x2880 captured, downscaled to 1080p)
Recording details from logs: 213 frames captured in a short test, encoder uses AVFoundation/VideoToolbox hardware encoding, NV12 pixel format
The recording itself completes successfully (output.mp4 is created locally) — the issue is in the export/rendering step, not the recording step
Desktop logs location: ~/Library/Logs/so.cap.desktop/

[linear]

CAP-665

[tembo]

Looking at the codebase, the "Rendering video (0/X frames)" progress is managed by the export pipeline in crates/export/src/mp4.rs. The rendering starts in export_render_to_channel() which spawns cap_rendering::render_video_to_channel_nv12() to produce frames that are then forwarded to the encoder.

A few things that might help diagnose this:

Relevant code paths:

• Progress tracking: apps/desktop/src/routes/editor/ExportPage.tsx (around line 1573) - RenderProgress component displays the frame count
• Export entry point: apps/desktop/src-tauri/src/export.rs - do_export() sends initial FramesRendered { rendered_count: 0, total_frames } then updates as frames complete
• Core rendering loop: crates/rendering/src/lib.rs:866-874 - the main frame iteration loop

Potential issue area:
The recent PR #1675 (merged March 23) restructured the export pipeline for performance. The Greptile review on that PR flagged a concern about missing timeout protection in one code path (lines 481-482), noting that if the GPU renderer stalls, recv() could block indefinitely with no error or progress update - which matches the symptoms here.

The timeout constants are still defined (FRAME_RECEIVE_INITIAL_TIMEOUT_SECS = 120, FRAME_RECEIVE_STEADY_TIMEOUT_SECS = 90) and used in export_render_to_channel, but it's worth verifying the complete path is covered for long recordings.

Diagnostic suggestions:

1. The debug println!() statements in crates/rendering/src/lib.rs:1282-1290 (get_duration()) would show the calculated duration - checking logs at ~/Library/Logs/so.cap.desktop/ for these messages could confirm whether total_frames is calculated correctly
2. With 65,328 frames at typical 30fps, that's ~36 minutes which means rendering could take a while to even emit the first frame due to pipeline setup (cursor precomputation, zoom interpolation setup, etc.)
3. The high resolution source (5120x2880) might be causing memory pressure or GPU stalls during the initial setup phase

Related issue:
#1449 reports screen recording freezing on macOS with M4 Pro - different symptom but same general area (macOS + Studio Mode + rendering pipeline).

[m13v]

we hit something very similar building a session replay SDK that captures macOS screens at 5 FPS with H.265 hardware encoding. the pipeline stall at frame 0 with high-res input is a classic VideoToolbox issue.

the pattern we saw: when the source resolution is very high (5120x2880 in your case), the initial VideoToolbox encoder session setup can block for a long time while the hardware encoder allocates its internal buffers. if the rendering pipeline sends frames via a channel before the encoder is ready to consume them, the channel fills up and the whole pipeline deadlocks. the recv() blocking issue that tembo flagged sounds exactly like this - the renderer is waiting to send a frame, the encoder is waiting to finish setup, nobody makes progress.

our fix was a two-phase approach: first do a single-frame encode warmup with a blank NV12 buffer at the target resolution before starting the real pipeline. that forces VideoToolbox to complete its hardware setup synchronously. then start the real rendering loop. for 5K source downscaled to 1080p, also worth checking that the pixel transfer from source to NV12 isn't the bottleneck - CVPixelBufferPool reuse helps a lot there.

[m13v]

our ScreenCaptureKit-based recording service that handles the video capture pipeline, H.265 hardware encoding, and the CVPixelBuffer management: https://github.com/m13v/macos-session-replay/blob/main/Sources/SessionReplay/ScreenCaptureService.swift

and the video chunk encoder that handles VideoToolbox session setup and buffer pooling: https://github.com/m13v/macos-session-replay/blob/main/Sources/SessionReplay/VideoChunkEncoder.swift

[richiemcilroy]

Hey! This should be much better in 0.4.81, just released :)

[m13v]

Nice, thanks for the quick turnaround! Will give 0.4.81 a spin.