Repository navigation
Conversation
|
No actionable comments were generated in the recent review. ℹ️ Recent review info
Walkthrough
Merge Risk:
 |
| Check name | Status | Explanation |
|---|---|---|
| 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. |
| Title check | |
The title clearly summarizes the primary change: maintaining continuous macOS webcam recordings by preferring VP8. |
| Description check | |
The description covers the change, related issue status, bug-fix and patch classification, macOS impact, testing scope, results, and known limitations. It does not use the template's exact Summary hea… |
Full details: Description check
-
Explanation
The description covers the change, related issue status, bug-fix and patch classification, macOS impact, testing scope, results, and known limitations. It does not use the template's exact Summary heading, but the required summary information is present.
✨ Finishing Touches
-
🧪 Generate unit tests (beta)
-
- 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.
Comment @coderabbitai help to get the list of available commands.
EtienneLescot
left a comment
EtienneLescot
left a comment
There was a problem hiding this comment.
Thanks for the detailed report. We measured this on an M1 Mac mini (macOS 27) inside the app's own Chromium, with the recorder options from main and from this PR, 60 s per take:
| Take | Frames | fps | Max gap | Gaps > 100 ms | CPU |
|---|---|---|---|---|---|
| H.264, 1080p | 1799 | 30.0 | 76 ms | 0 | 30 % |
| VP8, 1080p | 1799 | 30.0 | 65 ms | 0 | 156 % |
| H.264, 2160p | 1799 | 30.0 | 66 ms | 0 | 72 % |
| VP8, 2160p | 1082 | 18.2 | 1299 ms | 54 | 348 % |
The 2160p source was the camera upscaled frame by frame to 3840×2160, since our only camera there tops out at 1080p. The source delivered ~1800 frames; the VP8 encoder dropped the rest.
So VP8 holds 1080p (at about five times the CPU), but not the default 2160p preset: there it produces the same kind of frozen webcam the PR sets out to fix. We couldn't reproduce the H.264 stall with our virtual camera. That doesn't rule it out on a C922, but it means we can't trade it for a certain stall at 4K. Could you limit VP8 to takes the camera delivers at 1080p or below, and keep H.264 above that? Any other approach that holds 30 fps at 2160p on Apple Silicon works too.
The compositor change is good and needed on its own. With main's addon a VP8 webcam is missing from the export entirely; with yours it exports smoothly, and H.264 exports are bit-identical. The new Rust test passes on Apple Silicon. Feel free to split it into its own PR if you'd like it merged first.
Please also rebase: the checklist row conflicts with main.
|
Follow-up after longer tests: the blanket VP8 preference in this PR needs to change. Your 4K measurements exposed a CPU cost that the initial short 1080p takes missed. On the affected M3 Pro, camera capture kept delivering about 30 fps while hardware H.264 encoding stalled during simultaneous native screen and webcam recording. One 60-second trace had 1,800 renderer inputs, eight GPU encode calls and one encoded output. Process sampling found I also reproduced the frozen tail with the built-in FaceTime HD camera on macOS 27.2: H.264 stopped after 52 frames at 1.701 s while the screen recorded 125.900 s. Checking only camera track FPS, container duration or gaps between existing packets missed this failure. Two local changes now work together:
app.commandLine.appendSwitch("disable-accelerated-video-encode");A trace confirmed Results on the local v2.0.0-based build, Electron 41.2.1 / Chromium 146.0.7680.188, FaceTime HD at 1080p30, with screen and microphone recording:
The final take decoded completely with 6,111 distinct camera frames. Its full UI MP4 export had 6,096 frames, clean video/audio decoding and 6,096 distinct camera-region images. The comparison's recording renderer averaged 51.9% CPU over 45 seconds, where 100% is one core; that excludes the native recorder and Apple's encoder service. This validates a local 1080p workaround. The C922 was disconnected for the latest tests, and software H.264 at 4K has not been measured. These changes are not on this PR branch yet. I recommend keeping H.264 as the upstream default while working out a targeted software fallback for affected recordings. The codec-aware compositor path and WebM metadata fixes in this PR remain useful independently. Further hardware isolation on the same Mac: a minimal MediaRecorder process using the actual frame-copy code, FaceTime HD at 1080p30, and native screen/microphone capture passed with 1,798 frames through 59.909 s (max gap 53 ms). A 90-second synthetic 1080p30 run alongside a second native 4K encoder saved 2,697 frames through 89.868 s (max gap 44 ms). Traces confirmed hardware encoding. A separate synthetic stress case is reproducible: with two 4K streams, MediaRecorder saved only 186 frames through 6.17 s from 30 s of input, twice. Output kept arriving but fell far behind wall time. The native foreground control completed all 900 frames, with submission stretched to 32.51 s. A single MediaRecorder 4K stream passed. Reducing the second stream to 30 fps still left a large backlog. This supports keeping hardware H.264 as the upstream default. The original 1080p app freeze remains unexplained by the minimal tests; the blocked VideoToolbox stack alone does not identify a Chromium defect. The software switch remains a local workaround, while the synthetic backlog gives us a smaller case to investigate. |
Follow-up, 2026-10-27
The blanket VP8 preference needs revision. The review measured dropped frames at 4K, and later local traces found separate camera-buffer and hardware H.264 encoding stalls.
The local workaround now copies camera pixels into owned frames and uses software H.264 through Chromium's
disable-accelerated-video-encodeswitch on macOS. It passed simultaneous screen, microphone and 1080p30 camera recording, pause/resume, playback and full MP4 export. The final camera take ran for 203.829 s at 29.976 fps, with a maximum frame gap of 69 ms. Software H.264 at 4K still needs measurement.The branch currently contains the original VP8 proposal below. The frame-copy and software-H.264 changes are local; the follow-up comment records the diagnosis, exact workaround and test scope. The compositor and WebM metadata fixes remain applicable independently.
Original proposal
On macOS, MediaRecorder's H.264 webcam encoder can stop producing frames while the camera stream stays live. A local reproduction with a Logitech C922 produced only 13 frames over 56 seconds; VP8 produced 3,828 frames over 128 seconds with a maximum frame gap of 68 ms. A second installed-build take produced 1,932 frames over 64 seconds, maximum gap 66 ms.
Prefer VP8 for macOS webcam recording, independently of the native H.264 screen recorder. Keep the existing H.264 preference on Windows/Linux and negotiate supported fallbacks. Check the codec's VideoToolbox configurations before selecting hardware presentation: VP8 CPU frames need the existing NV12/CVPixelBuffer conversion to appear in the Metal compositor. Preserve unknown-sized WebM Cluster bytes when patching duration, including recordings under 2 MB.
The machine-specific build/install scripts used for local testing are excluded. Autofocus and camera constraints are unchanged. The held-screen preview clock fixes already on main address a separate editor-only freeze.
Related issue
No issue linked; reproduced locally on macOS.
Type of change
Release impact
Desktop impact
Screenshots / video
Private camera recordings were checked locally and are not attached. The testing checklist records the measured continuity and the partial desktop smoke-test scope.
Testing of the original PR patch
Summary by CodeRabbit