Repository navigation
Conversation
… does Two cells in the "Platform differences" table on the installation page still described Linux as it was before the native compositor learned VAAPI, and one row disagreed with the README about the webcam. MP4 export on Linux is no longer "software encode". Since 6ba8f4c the export opens h264_vaapi against a dmabuf exported from the compositor when the driver offers VAAPI, and only falls back to the software encoder when it does not (no render node, no VAAPI); H.265 still goes to the software encoder in every case (pipeline_linux.rs only tries VAAPI for H264). The note under the table said the opposite and pointed at a roadmap entry for work that has landed, so it now describes the actual selection and what the fallback costs. The webcam row said macOS captured the camera natively. It does not: the mac helper decodes a `webcam` field and never touches a camera device, and useScreenRecorder records the camera with a MediaRecorder in the renderer and attaches the file afterwards, exactly as on Linux. Windows is the platform that muxes it into the recording. The row now says what README.md already says, for all three columns. The capture-pipeline row raised in getopenscreen#535 was already corrected by 1c66ca3. Fixes getopenscreen#535
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 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 |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 05111485d8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| | Capture pipeline | Native (ScreenCaptureKit) | Native (Windows Graphics Capture) | Native (PipeWire via the ScreenCast portal); browser fallback without the helper, losing hardware encode and cursor telemetry | | ||
| | Custom cursor themes / click effects | ✅ | ✅ | ✅ on Wayland — click capture needs the `input` group ([details](#mouse-clicks-on-wayland)) | | ||
| | Webcam | Native capture | Native capture | Browser capture (still works as PiP) | | ||
| | Webcam | Browser capture, saved as a separate file (still works as PiP) | Native capture, muxed into the recording | Browser capture, saved as a separate file (still works as PiP) | |
There was a problem hiding this comment.
For every normal Windows recording with the webcam enabled, electron/ipc/handlers.ts supplies a non-empty outputs.webcamPath, and the WGC helper uses that to enable writeSeparateWebcam and encode the camera to its own MP4. Therefore the camera is captured natively but is not muxed into the screen recording; this cell should describe the separate native webcam file rather than contradicting the current recording path.
Useful? React with 👍 / 👎.
|
|
||
| :::note MP4 export on Linux | ||
| The GPU compositor behind the live preview and MP4 export has three backends — Direct3D 11 on Windows, Metal on macOS, wgpu/WGSL on Linux — and ships in all three builds. The Linux one encodes in software rather than on the GPU, so an export there takes longer than the same one on Windows or macOS; hardware encode is tracked on the [roadmap](https://github.com/getopenscreen/openscreen/blob/main/ROADMAP.md). | ||
| The GPU compositor behind the live preview and MP4 export has three backends — Direct3D 11 on Windows, Metal on macOS, wgpu/WGSL on Linux — and ships in all three builds. On Linux, an H.264 export hands each composited frame to `h264_vaapi` without a CPU copy when the GPU driver exposes VAAPI. When it does not — no render node, or a driver without VAAPI — the export falls back to a software encoder and simply takes longer; nothing else changes. H.265 exports always use the software encoder on Linux. |
There was a problem hiding this comment.
On a machine whose driver exposes VAAPI but lacks either VK_KHR_external_memory_fd or VK_EXT_external_memory_dma_buf, open_device_with_dmabuf_export returns the ordinary wgpu device and the hardware sink is rejected when exportable staging is created, so H.264 still falls back to software. This sentence currently tells those users that exposing VAAPI alone is sufficient and lists only missing render nodes or VAAPI as fallback causes; qualify the hardware path on the required Vulkan external-memory/dmabuf support as well.
Useful? React with 👍 / 👎.
…needs dmabuf export Two corrections from reading the code once more after the first pass. Windows does not mux the webcam into the recording. handlers.ts computes a webcam output path for every native Windows recording and passes it as outputs.webcamPath, and the WGC helper turns a non-empty path into writeSeparateWebcam, so the camera goes to its own MP4 through a second MFEncoder. The "muxed into the primary MP4" branch in the helper exists but nothing in the app takes it. The table cell and the README sentence that claimed the mux now say "separate file" like the other two platforms; what still differs is that Windows captures the camera in the helper while macOS and Linux record it in the app. The VAAPI export needs more than a driver that exposes VAAPI. The compositor opens its wgpu device with VK_KHR_external_memory_fd and VK_EXT_external_memory_dma_buf (d3d_linux.rs, open_device_with_dmabuf_export) and only then can hand a frame to h264_vaapi as a dmabuf; without those the hardware sink is rejected and H.264 goes to the software encoder as well. The note under the table now names that condition, and the fallback list includes it.
Summary
Problem. The Platform differences table on the installation page still described Linux MP4 export as
software encode, the note under it said the Linux compositor "encodes in software rather than on the GPU" and pointed at a roadmap entry for hardware encode, and the webcam row said macOS captures the camera natively. None of that matches the code onmain.What the code does, checked against the source rather than the docs:
feat(export): encode on the GPU when VAAPI is available (Linux)),crates/compositor/src/pipeline_linux.rsopensh264_vaapiagainst a dmabuf exported from the compositor when the driver offers VAAPI, and only falls back to the software encoder when it cannot: no render node, no VAAPI, or a wgpu device opened withoutVK_KHR_external_memory_fd/VK_EXT_external_memory_dma_buf(d3d_linux.rs,open_device_with_dmabuf_export), in which case the hardware sink is rejected before the first frame. The VAAPI attempt is guarded bymatches!(params.codec, ExportCodec::H264), so H.265 always goes tolibkvazaar. The row and the note now say exactly that, and the roadmap link is gone because it pointed at work that has landed.src/lib/nativeMacRecording.tscarries awebcamfield in the helper request, butScreenCaptureRecorder.swiftonly decodes it and never opens a camera device (itsAVCaptureDevicecalls are all.audio);src/hooks/useScreenRecorder.tsrecords the camera with aMediaRecorderin the renderer and attaches the file afterwards, andnativeLinuxRecording.tsdocuments the Linux path as "Like macOS, the camera stays with the renderer's MediaRecorder". On Windows the helper captures the camera itself, butelectron/ipc/handlers.tspassesoutputs.webcamPathon every recording andwgc-capture/src/main.cppturns that intowriteSeparateWebcam, so it is written to its own MP4 rather than muxed; the helper's mux branch exists but nothing in the app takes it. The row now says that for all three columns, and the one README sentence that claimed Windows muxes the webcam says the same. Those are cells beyond the Linux column the issue is about; they are the same row, checked the same way, and leaving cells I had just found wrong felt worse than touching them — happy to split them out if you would rather keep this PR Linux-only.Not in this PR.
ROADMAP.mdlines 42 and 47 still say the Linux export is software-encoded and list "Hardware encode on Linux" as open. That is the same staleness, but ticking a roadmap item is your call, so I left it and am flagging it here.Related issue
Fork rehearsal of the upstream fix for issue 535 (
docs: Linux rows in the platform-differences table predate the native capture helper). Not linked on purpose so the upstream issue gets no cross-reference from this rehearsal; the upstream PR will carryFixes.Type of change
Release impact
Desktop impact
Docs only; the macOS tick is for the webcam cell.
Screenshots / video
n/a
Testing
npm run docs:checkat the root:check-docs: OK (34 files).website/(npm ci && npm run build), rerun after the second commit:[SUCCESS] Generated static files in "build"; the builtdocs/installation/index.htmlrenders the table with the new cells and no longer mentions the roadmap.mainfbe461e; I have no Linux machine, so the VAAPI selection itself is the maintainer's measurement in upstream issue 535 plus the source, not something I re-ran.