[EtienneLescot]

Summary

Likely cause of #1475: the Windows capture helper never sets a GOP size, so the H.264 encoder picks its own key frame spacing. With GOP 0, which is the default, some vendors' encoders write a single key frame at the start of the take.

The editor seeks to the key frame before its target and decodes forward. On a take with one key frame, every seek decodes from the start of the take: at a cut, on pause, or when the drift watch re-anchors. This matches the report:

• the picture freezes and the audio keeps going;
• CPU stays low, because decoding runs on the GPU;
• short takes are fine, and a 10-minute take waits minutes;
• export works, because it decodes in one forward pass.

This PR sets CODECAPI_AVEncMPVGOPSize to the frame rate, which gives one key frame per second for the screen and the camera.

Measurements

The editor's seek mechanism, timed with ffmpeg -hwaccel d3d11va -ss T on synthetic 10-minute 1080p60 H.264 takes (RTX 4070 Ti):

Seek target	GOP 60 (1 s)	single key frame
5 s	0.52 s	1.0 s
60 s	0.46 s	7.5 s
480 s	0.44 s	78.6 s

The helper's encoder test (new case key-frame-interval), 4 s at 30 fps:

• before: up to 90 frames between key frames on both the software and the default encoder;
• after: 30 frames.

The other 24 helper tests still pass.

Not measured

• The reporter's files. They are on a private Drive and could not be opened here. The single-key-frame theory fits the symptoms but is not confirmed on their take. ffprobe -skip_frame nokey -show_entries frame=pts_time on their screen file would settle it.
• The reporter's encoder. No AMD GPU here. On this NVIDIA machine, existing takes already have a key frame every ~1 s, so in-app frame rate, seek and dropped-frame numbers before and after would be the same here. They do not prove anything about the reporter's encoder.
• Existing takes. Takes already recorded with a long GOP stay slow to seek. Fixing them needs a change in the compositor or a re-encode, which is a separate decision.

Touches electron/native/**, so evidence is needed. File size: one key frame per second instead of the encoder's own spacing (3 s on the Microsoft software encoder, ~1 s on NVIDIA here).

Refs #1475

🤖 Generated with Claude Code

Summary by CodeRabbit

• Improvements
  • Video encoding now places keyframes at approximately one-second intervals. This provides more consistent keyframe spacing in captured video while preserving the existing behavior of disabling B-frames.

[coderabbitai]

No actionable comments were generated in the recent review.

Walkthrough

The encoder now requests a GOP size equal to its frame rate, alongside the existing setting that disables B-frames. Tests write video with software and default encoders and check the output frame count and key-frame interval.

Changes: Encoder GOP interval

Layer / File(s)	Summary
Set and verify GOP interval electron/native/wgc-capture/src/mf_encoder.cpp, electron/native/wgc-capture/src/mf_encoder_color_test.cpp	The encoder requests a GOP size equal to its frame rate. Tests check that 120 frames are present and that no interval between key frames exceeds 30 frames for both software and default encoders.

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Possibly related issues

• Issue 1475: The reported delays during seeking, pausing, or cuts may be related to key-frame spacing. The issue does not establish GOP spacing as the cause.

Merge Risk: Minimal · up to c0775

The change makes screen and camera recordings seek faster by requesting about one key frame per second. The remaining limitation is an unusual configuration where a very low screen frame rate is combined with a higher webcam rate, and it does not block merging.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title clearly and concisely describes the main change: configuring captures to write a key frame every second on Windows.
Description check		The description includes a detailed summary, related issue reference, measurements, testing results, limitations, and affected area. The type of change, release impact, and desktop impact checkboxes a…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Description check

Explanation

The description includes a detailed summary, related issue reference, measurements, testing results, limitations, and affected area. The type of change, release impact, and desktop impact checkboxes are not selected, but the description is otherwise substantially complete.

Finishing Touches

Generate docstrings

• Commit to this branch
• Create a new PR

Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

• X
• Mastodon
• Reddit
• LinkedIn

Recent review info

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: 25d2226e-7c17-4d00-912d-5f28e7310c7d

Commits

Reviewing files that changed from the base of the PR and between bc11fc4 and c07750c.

Files selected for processing: 2

• electron/native/wgc-capture/src/mf_encoder.cpp
• electron/native/wgc-capture/src/mf_encoder_color_test.cpp

Included review availability: This review used your included allowance. Your plan provides up to 8 included reviews per hour; 6 remain after this review.