Shotcut Hardware Encoding: Which Codecs Are Supported?

Shotcut's official documentation gives two different answers to this question, and both are on the record in the same PDF. The User Guide's Export Basics section says hardware encoding covers H.264 and HEVC only. The Hardware Encoding section that follows names AV1 encoders by their filenames, and the release notes record AV1 hardware encoders being added three separate times.

If you are trying to work out whether a specific codec will actually run on your GPU, that gap is the whole story. Here is what each official source says, with the qualifiers the guide attaches to them.

What the official sources name, at a glance

The names decode predictably, and the guide spells out both halves: the prefix is the codec, the suffix is the backend.

_vaapi -- Linux VAAPI backend
_nvenc -- NVIDIA hardware encoder

It adds that "NVENC is NVIDIA's proprietary hardware encoder." and that "VAAPI (Video Acceleration API) is commonly used on Linux systems." So hevc_nvenc is HEVC through NVIDIA's encoder and h264_vaapi is H.264 through VAAPI — once you know the rule, an unfamiliar entry in the Configure dialog stops being a mystery.

Two things about this table. First, the release-note rows describe what a given version changed, not a statement about today — treat them as "this backend existed by that release," not as a guarantee about your build. Second, the User Guide's own explainer, "Common hardware encoder types explained," only covers VAAPI and NVENC. AMF, Quick Sync, VideoToolbox and Media Foundation have no matching section in the guide we read, so everything above about them comes from release notes.

The contradiction, in the official wording

Under Export Basics, describing the hardware encoder option, the guide says:

"This feature currently only supports the H.264 (aka AVC) and HEVC (aka H.265) codecs."

The Hardware Encoding section of the same guide then lists encoders, including these entries verbatim:

av1_vaapi -- AV1 encoding using VAAPI (if supported)
av1_nvenc (newer GPUs only)
av1 -- Very efficient, newest standard, limited hardware support

And the release notes record AV1 hardware encoders being added on three occasions: "Added support for Intel (“qsv”) AV1 and VP9 hardware encoders on Windows including 10-bit for AV1." (Release 23.05.07), "Added support for av1_nvenc NVIDIA AV1 hardware encoder on Windows and Linux." (Release 23.11.29), and "Added support for AMD AV1 hardware encoder on Windows (av1_amf) and Linux (av1_vaapi)." (Release 24.02.29).

The practical reading: do not take either page as a guarantee. The AV1 entries carry hedges that the H.264 and HEVC entries do not — "(if supported)", "(newer GPUs only)", and "limited hardware support". H.264 and HEVC are the two the guide is willing to state flatly.

Why "supported by Shotcut" is the wrong question

Shotcut does not ship a fixed codec list per platform. The guide describes detection instead: "Shotcut automatically scans the system and lists all hardware encoders it can access on the current operating system."

That makes the Configure dialog, not the documentation, the authority for your machine. The guide is explicit about what a greyed-out or unticked entry means: "Unchecked options mean: The encoder exists in Shotcut But is not available on your system." In other words, unchecked is not "disabled" — it is "your hardware, drivers or OS do not expose it."

The guide lists what availability depends on:

• Your GPU vendor (Intel, AMD, NVIDIA)
• Installed drivers
• Operating system support
• Enabled APIs (VAAPI, NVENC, etc.)

For NVENC specifically, the entries "appear only if: An NVIDIA GPU is present Proper NVIDIA drivers are installed", and "If unchecked, it usually means no NVIDIA GPU is detected." The Quick Start Guide is blunter about the failure case: "If nothing is detected then your graphics card is not compatible." Click Configure, then Detect, to set it. If you have hit the same wall in other apps, the pattern is similar in HandBrake's greyed-out NVENC and QSV entries and in DaVinci Resolve's hardware acceleration settings.

What to do when the codec you want is not offered

Pick a codec your system actually lists, then deal with the consequence. The guide is clear that hardware encoding trades file size, not picture: "Hardware encoding is usually less compression-efficient, not lower quality," and "File sizes may be larger at the same quality target." So a hardware-encoded H.264 export that comes out bigger than a software one is expected behaviour, not a bug.

If that larger file is the actual problem — an upload cap, a mail attachment, a chat window — shrink it after export rather than fighting the encoder list:

This runs in your browser tab, so the export never leaves your machine. For the same job on other footage, compress video is the standalone page, and all Clapr tools lists the rest.

The guide's own recommendation splits the choice cleanly. Enable hardware encoding for "Long exports High-resolution video Preview or draft renders Laptop or low-power systems". Prefer software encoding for "Maximum compression efficiency Archival-quality exports Advanced codec tuning".

Gotchas the docs name explicitly

• 10-bit H.264 is a software-only path. Release 26.6.25 records the fix "10-bit H.264 encoder fails with hardware encoding on," and explains: "No H.264 hardware encoders support 10-bit; this change simply makes it use software encoding with x264." That limit is specific to H.264 — the same release notes record 10-bit fixes for NVENC, AMF and Media Foundation encoders elsewhere.
• HDR metadata skips hardware encoders entirely. Release 26.6.25 also states: "Export only embeds PQ HDR metadata for the libx265 and libsvtav1 video codecs and no hardware encoders."
• Presets are not automatically compatible. The guide warns that "Some export presets may not support hardware encoders," and that if a preset is used where the encoder is unavailable, "The export may fail Shotcut may fall back to software encoding Results may differ from expectation." Those are two listed possibilities, not a promise of a silent fallback.
• The checkbox overrides the preset's codec, with one stated exception: it "will still affect which codec is used unless you choose a hardware codec that Shotcut does not manage, for example ProRes."
• Your CPU will still be busy. The FAQ explains that reading and decoding files "becomes a bottleneck to feed the hardware encoder," so near-zero CPU usage is not the expected result.

FAQ

Does Shotcut hardware encoding support AV1? The User Guide lists av1_vaapi and av1_nvenc among hardware encoders, and the release notes record AV1 hardware encoders being added for Intel, NVIDIA and AMD. But the Export Basics section of the same guide says the feature currently supports only H.264 and HEVC, and every AV1 entry carries a hedge — "(if supported)", "(newer GPUs only)", "limited hardware support". Check the Configure dialog on your own system.

Why are most encoders unchecked in the Configure dialog? Per the guide, unchecked means the encoder exists in Shotcut but is not available on your system. Availability depends on your GPU vendor, installed drivers, operating system support, and enabled APIs.

Shotcut detected nothing at all. What now? The Quick Start Guide's answer is direct: if nothing is detected, your graphics card is not compatible. Export with software encoding instead, and see the limits hub for other export ceilings worth knowing.

Why is my hardware-encoded export larger than the software one? Because that is the documented trade. The guide says hardware encoding is "usually less compression-efficient, not lower quality," and that file sizes may be larger at the same quality target.

Can I export 10-bit H.264 with hardware encoding on? Release 26.6.25 states that no H.264 hardware encoders support 10-bit, and that Shotcut uses software encoding with x264 in that case.

All quotations are from the Shotcut User Guide (June 2026 edition), the official FAQ, and the official release notes, checked 19 September 2026. Encoder availability changes with drivers and releases — verify in Configure before relying on it.