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
GPU video encoding is untested on Intel, AMD, Linux and macOS hardware #792
The GPU encoder was built and measured on NVIDIA (NVENC) on Windows. Auto is on by default. Intel QSV, AMD AMF, VAAPI on Linux and VideoToolbox on macOS have never run a real render, and the shipped Linux desktop ffmpeg has no GPU encoder at all. The check that decodes the whole GPU file afterwards costs 18 to 21 percent of the render time.
Who is affected
Every user whose graphics card is not NVIDIA, and every macOS and Linux user.
How to see it
Run python scripts/encoder_matrix.py on a Mac, an Intel or AMD PC and a Linux box with VAAPI, and compare with the CPU result. Then export a one-minute take on each with Auto.
Evidence
scripts/encoder_matrix.py and tests/test_encoder_matrix.py (passes here: 145 tests across four files).
app/pipeline/video_encoder.py:932-940 decodes the whole output with -f null.
Results so far are from the session: NVENC only.
Constraints for anyone fixing it
Platforms: Windows, macOS and Linux each ship a different ffmpeg; see .claude/skills/release for how.
If a code change adds a dependency, uv.lock may change, and that forces a full download for every desktop install (desktop-update-gate).
The result belongs in the release notes if Auto is left on.
Origin
NEW in 0.21.0 (3b101bb). Found on the big-release branch (draft pull request #784); the work is not released yet.
Possible direction
Decide whether Auto stays on for hardware that was not tested. A cheaper check (key frames only, 0.4 to 1.0 s in the earlier measurement) would remove most of the 18 to 21 percent.
GPU video encoding is now checked on NVIDIA under Windows. Intel, AMD, Linux and macOS are still untested, so this issue stays open for those.
What I ran on an RTX 3080 (driver 616.64, ffmpeg 8.1):
Auto chose h264_nvenc. The output decodes cleanly: H.264 High, 1920x1080 at 30 fps, AAC, exact duration.
A 60 second take rendered in 7.7 seconds with Auto and 10.3 seconds on the CPU. A 6 second take was faster on the CPU, so the GPU encoder pays off on longer takes.
scripts/encoder_matrix.py reports 6.0x realtime for NVENC at 1080p against 1.1x for the CPU encoder.
Decoding the whole file again after the render took about 16 percent of the render time.
On this PC the QSV and AMF probes fail (no Intel or AMD GPU), and Auto still picks NVENC and exports normally. A GPU encoder that does not pass its probe is not used.
If you have an Intel or AMD graphics card, a Mac or a Linux machine with VAAPI, python scripts/encoder_matrix.py and a one-minute export with Auto would settle it. Setting the encoder to CPU in Settings is always available if a GPU encoder misbehaves.
Thanks to anyone who can try it. Let me know how it goes.
Activity
fix(export): Auto uses only the GPU encoder measured in real exports (#…
thcp commentedon Nov 4, 2026
GPU video encoding is now checked on NVIDIA under Windows. Intel, AMD, Linux and macOS are still untested, so this issue stays open for those.
What I ran on an RTX 3080 (driver 616.64, ffmpeg 8.1):
h264_nvenc. The output decodes cleanly: H.264 High, 1920x1080 at 30 fps, AAC, exact duration.scripts/encoder_matrix.pyreports 6.0x realtime for NVENC at 1080p against 1.1x for the CPU encoder.On this PC the QSV and AMF probes fail (no Intel or AMD GPU), and Auto still picks NVENC and exports normally. A GPU encoder that does not pass its probe is not used.
If you have an Intel or AMD graphics card, a Mac or a Linux machine with VAAPI,
python scripts/encoder_matrix.pyand a one-minute export with Auto would settle it. Setting the encoder to CPU in Settings is always available if a GPU encoder misbehaves.Thanks to anyone who can try it. Let me know how it goes.