You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Rendered video has flickering artifacts and severe playback lagging. #1557
The exported video has significant technical issues. Specifically:
Visual Flickering: The final video flashes or flickers constantly, making it impossible to watch.
Preview & Playback Lag: Both the preview within the app and the final rendered file are extremely laggy (low frame rate), failing to capture the smoothness of the original screen activity.
Reproduction
Launch Cap and select a recording area (or full screen).
Record for a few seconds (e.g., scrolling a webpage or moving app windows).
Stop the recording to trigger the rendering/saving process.
Preview the video in Cap or open the exported file in a media player.
Observe the flickering artifacts and choppy playback.
The issue seems related to how the app handles hardware encoding on high-refresh-rate displays.
I am using a dual-GPU laptop (Intel + NVIDIA). The flickering might be caused by a conflict with NVIDIA NVENC or the Windows/Linux compositor during rendering.
Recent Work:
PR #1482 (merged Jan 4) added significant Windows hardware acceleration improvements including D3D11 zero-copy texture sharing and NV12 rendering optimizations. PR #1506 (merged Jan 12) added an experimental FFmpeg decoder fallback option for export issues. Since you're on v0.4.3 and these issues persist, it suggests the dual-GPU configuration may need additional handling.
Relevant Code Areas:
The Windows screen capture and encoding pipeline lives primarily in:
crates/scap-direct3d/ - Windows Graphics Capture API implementation
crates/enc-mediafoundation/ - Hardware encoding via MediaFoundation (H.264/HEVC)
The encoder has health monitoring for stall detection and hardware failures (crates/enc-mediafoundation/src/video/h264.rs:41-61), which may be getting triggered on hybrid GPU setups where the discrete GPU isn't being consistently used.
Potential Workaround:
If there's an option to force a specific GPU in Windows graphics settings for Cap, try forcing it to use the NVIDIA RTX 3060 rather than letting Windows auto-select. This has helped with similar issues in other screen recording tools on hybrid GPU laptops.
Additional Context That Would Help:
Are the raw .cap recording files also affected, or only the exported video?
Does disabling hardware acceleration (if such a setting exists) change the behavior?
Does the issue occur at lower display refresh rates (e.g., setting Windows to 60Hz temporarily)?
2026-01-28T17:41:20.280519Z INFO recording:studio_recording:segment{index=0}:screen-out: cap_frame_converter::d3d11: Enumerated 3 GPU adapter(s) 2026-01-28T17:41:20.280611Z INFO recording:studio_recording:segment{index=0}:screen-out: cap_frame_converter::d3d11: Multi-GPU system detected (3 GPUs). Selected NVIDIA GeForce RTX 3060 Laptop GPU with 5994 MB VRAM for encoding. 2026-01-28T17:41:20.431572Z INFO recording:studio_recording:segment{index=0}:screen-out: cap_enc_ffmpeg::mux::segmented_stream: Initialized segmented video encoder with FFmpeg DASH muxer (init.mp4 + m4s segments). CRITICAL: init.mp4 is required for segment playback/recovery. path=C:\Users\Admin\AppData\Roaming\so.cap.desktop\recordings\The Agent Skills Directory - Google Chrome (Window) 2026-01-29 12.41 AM.cap\content\segments\segment-0\display segment_duration_secs=3 width=1850 height=1530 2026-01-28T17:41:20.434606Z INFO recording:studio_recording:segment{index=0}:screen-out: cap_recording::output_pipeline::win_fragmented_m4s: Started Windows M4S fragmented video encoder path=C:\Users\Admin\AppData\Roaming\so.cap.desktop\recordings\The Agent Skills Directory - Google Chrome (Window) 2026-01-29 12.41 AM.cap\content\segments\segment-0\display 2026-01-28T17:41:20.434796Z INFO recording:studio_recording:segment{index=0}:screen-out: cap_recording::output_pipeline::core: Built pipeline for output C:\Users\Admin\AppData\Roaming\so.cap.desktop\recordings\The Agent Skills Directory - Google Chrome (Window) 2026-01-29 12.41 AM.cap\content\segments\segment-0\display 2026-01-28T17:41:20.443708Z INFO recording:studio_recording:segment{index=0}: cap_recording::studio_recording: pipeline playing 2026-01-28T17:41:20.464306Z INFO recording:studio_recording:segment{index=0}:cursor: cap_recording::cursor: Saved cursor 0 image to: "cursor_0.png" 2026-01-28T17:41:21.284580Z INFO recording:studio_recording:segment{index=0}:cursor: cap_recording::cursor: Saved cursor 1 image to: "cursor_1.png" 2026-01-28T17:41:24.330604Z INFO recording:studio_recording:segment{index=0}:cursor: cap_recording::cursor: Saved cursor 2 image to: "cursor_2.png" 2026-01-28T17:41:25.496598Z INFO recording:studio_recording:segment{index=0}:cursor: cap_recording::cursor: Saved cursor 3 image to: "cursor_3.png" 2026-01-28T17:42:18.191714Z INFO cap_recording::studio_recording: pipeline shuting down 2026-01-28T17:42:18.192075Z INFO recording:studio_recording:segment{index=0}:screen-out:{task="mux-video"}: cap_recording::output_pipeline::core: mux-video cancelled, draining remaining frames from channel 2026-01-28T17:42:18.192387Z INFO recording:studio_recording:segment{index=0}:screen-out:{task="mux-video"}: cap_recording::output_pipeline::core: mux-video finished after cancellation, total 1888 frames 2026-01-28T17:42:18.192412Z INFO recording:studio_recording:segment{index=0}:screen-out:{task="mux-video"}: cap_recording::output_pipeline::core: Task finished successfully 2026-01-28T17:42:18.196495Z INFO recording:studio_recording:segment{index=0}:screen-out:{task="d3d-capture-thread"}: cap_recording::output_pipeline::core: Task finished 2026-01-28T17:42:18.196672Z INFO recording:studio_recording:segment{index=0}:screen-out:{task="capture-video"}: cap_recording::output_pipeline::core: Task finished successfully 2026-01-28T17:42:18.196685Z INFO recording:studio_recording:segment{index=0}:screen-out:{task="d3d-capture"}: cap_recording::output_pipeline::core: Task finished successfully 2026-01-28T17:42:18.307345Z INFO cap_recording::studio_recording: pipeline shutdown 2026-01-28T17:42:18.307594Z INFO recording:studio_recording:segment{index=0}:cursor: cap_recording::cursor: cursor recorder done 2026-01-28T17:42:18.309708Z INFO recording: cap_desktop_lib::recording: recording wait actor done: Ok(()) 2026-01-28T17:42:18.311486Z INFO stop_recording: cap_desktop_lib::recording: Recording has fragments that need remuxing - opening editor immediately
Taking this. Starting with a local reproduction and the export frame timing to find where the flicker gets introduced during render. Will open a PR that references this issue.
Spent some time on this. On current main I can't reproduce it: exported three recordings (6s to 4min, 37-42fps sources) at 60fps and measured per-frame luma plus duplicate frames. No flicker pattern in any of them, and duplicates stayed under 1%, clustering around source-side capture gaps rather than the export. That points at this being fixed since the 0.4.x era. If anyone still sees it on 0.6.x, drop a recording (or share link) plus your platform and I'll dig into that case.
Activity
linear commentedon Jan 27, 2026
CAP-625
tembo commentedon Jan 27, 2026
Thanks for the detailed report. This appears related to several similar issues being tracked, particularly for Windows hybrid GPU configurations.
Related Issues:
Recent Work:
PR #1482 (merged Jan 4) added significant Windows hardware acceleration improvements including D3D11 zero-copy texture sharing and NV12 rendering optimizations. PR #1506 (merged Jan 12) added an experimental FFmpeg decoder fallback option for export issues. Since you're on v0.4.3 and these issues persist, it suggests the dual-GPU configuration may need additional handling.
Relevant Code Areas:
The Windows screen capture and encoding pipeline lives primarily in:
crates/scap-direct3d/- Windows Graphics Capture API implementationcrates/enc-mediafoundation/- Hardware encoding via MediaFoundation (H.264/HEVC)crates/recording/src/sources/screen_capture/windows.rs- Frame rate configurationThe encoder has health monitoring for stall detection and hardware failures (
crates/enc-mediafoundation/src/video/h264.rs:41-61), which may be getting triggered on hybrid GPU setups where the discrete GPU isn't being consistently used.Potential Workaround:
If there's an option to force a specific GPU in Windows graphics settings for Cap, try forcing it to use the NVIDIA RTX 3060 rather than letting Windows auto-select. This has helped with similar issues in other screen recording tools on hybrid GPU laptops.
Additional Context That Would Help:
.caprecording files also affected, or only the exported video?btbsb commentedon Jan 29, 2026
2026-01-28T17:41:20.280519Z INFO recording:studio_recording:segment{index=0}:screen-out: cap_frame_converter::d3d11: Enumerated 3 GPU adapter(s) 2026-01-28T17:41:20.280611Z INFO recording:studio_recording:segment{index=0}:screen-out: cap_frame_converter::d3d11: Multi-GPU system detected (3 GPUs). Selected NVIDIA GeForce RTX 3060 Laptop GPU with 5994 MB VRAM for encoding. 2026-01-28T17:41:20.431572Z INFO recording:studio_recording:segment{index=0}:screen-out: cap_enc_ffmpeg::mux::segmented_stream: Initialized segmented video encoder with FFmpeg DASH muxer (init.mp4 + m4s segments). CRITICAL: init.mp4 is required for segment playback/recovery. path=C:\Users\Admin\AppData\Roaming\so.cap.desktop\recordings\The Agent Skills Directory - Google Chrome (Window) 2026-01-29 12.41 AM.cap\content\segments\segment-0\display segment_duration_secs=3 width=1850 height=1530 2026-01-28T17:41:20.434606Z INFO recording:studio_recording:segment{index=0}:screen-out: cap_recording::output_pipeline::win_fragmented_m4s: Started Windows M4S fragmented video encoder path=C:\Users\Admin\AppData\Roaming\so.cap.desktop\recordings\The Agent Skills Directory - Google Chrome (Window) 2026-01-29 12.41 AM.cap\content\segments\segment-0\display 2026-01-28T17:41:20.434796Z INFO recording:studio_recording:segment{index=0}:screen-out: cap_recording::output_pipeline::core: Built pipeline for output C:\Users\Admin\AppData\Roaming\so.cap.desktop\recordings\The Agent Skills Directory - Google Chrome (Window) 2026-01-29 12.41 AM.cap\content\segments\segment-0\display 2026-01-28T17:41:20.443708Z INFO recording:studio_recording:segment{index=0}: cap_recording::studio_recording: pipeline playing 2026-01-28T17:41:20.464306Z INFO recording:studio_recording:segment{index=0}:cursor: cap_recording::cursor: Saved cursor 0 image to: "cursor_0.png" 2026-01-28T17:41:21.284580Z INFO recording:studio_recording:segment{index=0}:cursor: cap_recording::cursor: Saved cursor 1 image to: "cursor_1.png" 2026-01-28T17:41:24.330604Z INFO recording:studio_recording:segment{index=0}:cursor: cap_recording::cursor: Saved cursor 2 image to: "cursor_2.png" 2026-01-28T17:41:25.496598Z INFO recording:studio_recording:segment{index=0}:cursor: cap_recording::cursor: Saved cursor 3 image to: "cursor_3.png" 2026-01-28T17:42:18.191714Z INFO cap_recording::studio_recording: pipeline shuting down 2026-01-28T17:42:18.192075Z INFO recording:studio_recording:segment{index=0}:screen-out:{task="mux-video"}: cap_recording::output_pipeline::core: mux-video cancelled, draining remaining frames from channel 2026-01-28T17:42:18.192387Z INFO recording:studio_recording:segment{index=0}:screen-out:{task="mux-video"}: cap_recording::output_pipeline::core: mux-video finished after cancellation, total 1888 frames 2026-01-28T17:42:18.192412Z INFO recording:studio_recording:segment{index=0}:screen-out:{task="mux-video"}: cap_recording::output_pipeline::core: Task finished successfully 2026-01-28T17:42:18.196495Z INFO recording:studio_recording:segment{index=0}:screen-out:{task="d3d-capture-thread"}: cap_recording::output_pipeline::core: Task finished 2026-01-28T17:42:18.196672Z INFO recording:studio_recording:segment{index=0}:screen-out:{task="capture-video"}: cap_recording::output_pipeline::core: Task finished successfully 2026-01-28T17:42:18.196685Z INFO recording:studio_recording:segment{index=0}:screen-out:{task="d3d-capture"}: cap_recording::output_pipeline::core: Task finished successfully 2026-01-28T17:42:18.307345Z INFO cap_recording::studio_recording: pipeline shutdown 2026-01-28T17:42:18.307594Z INFO recording:studio_recording:segment{index=0}:cursor: cap_recording::cursor: cursor recorder done 2026-01-28T17:42:18.309708Z INFO recording: cap_desktop_lib::recording: recording wait actor done: Ok(()) 2026-01-28T17:42:18.311486Z INFO stop_recording: cap_desktop_lib::recording: Recording has fragments that need remuxing - opening editor immediatelylouis030195 commentedon Feb 4, 2026
Cap.2026-02-04.at.07.01.25.mp4
yep
ahmetcagatay commentedon Feb 9, 2026
I got flicker effect in gif (and also video render)
vagxrth commentedon Feb 9, 2026
Here's the how the rendered video looks with the flicker effect.
Cap Link: https://cap.so/s/hqqvjhsvgggf2kt
Cap.2026-02-09.at.21.42.39.mp4
SandrewSimon commentedon Feb 9, 2026
Also seeing this as well. Any workaround?
EzeCuervo commentedon Feb 10, 2026
I’m experiencing the same flickering issue after export. Everything looks fine while editing, but the problem appears in the exported file.
Context
tedy69 commentedon Feb 11, 2026
I’m experiencing the same flickering issue after export and preview is so lagging
Context
AlexW00 commentedon Feb 11, 2026
workaround: downgrade to 0.4.0 and re-export
AnthonyRonning commentedon Feb 11, 2026
Flickering. Not sure why or how this started happening all of a sudden. Completely unusable, wasted a whole recording.
fix: respect force_ffmpeg_decoder setting in export
sloemo01 commentedon Oct 14, 2026
Taking this. Starting with a local reproduction and the export frame timing to find where the flicker gets introduced during render. Will open a PR that references this issue.
sloemo01 commentedon Oct 14, 2026
Spent some time on this. On current main I can't reproduce it: exported three recordings (6s to 4min, 37-42fps sources) at 60fps and measured per-frame luma plus duplicate frames. No flicker pattern in any of them, and duplicates stayed under 1%, clustering around source-side capture gaps rather than the export. That points at this being fixed since the 0.4.x era. If anyone still sees it on 0.6.x, drop a recording (or share link) plus your platform and I'll dig into that case.