[Feature]: Hardware-accelerated video encode for Linux export

[rafaelvieiras]

Summary

MP4 export on Linux currently produces correct output but is much slower than on Windows or macOS, because the export pipeline decodes and encodes in software while Windows/macOS use hardware paths end-to-end.

This is already flagged in ROADMAP.md:

Hardware encode on Linux — the export path is correct but software-encoded, so it is slower than the Windows and macOS ones. The capture helper already uses a hardware H.264 encoder; the export pipeline does not.

I couldn't find an open issue tracking this specific item, so opening one for visibility/tracking.

Current behavior (from reading the code)

• crates/compositor/src/pipeline_linux.rs: decode is software (linux_decode::SwDecoder / linux_frames::CpuFrames), and the video encoder only tries libopenh264 (H.264) / libkvazaar (H.265) — both software, from the LGPL-shared ffmpeg build. No VAAPI or Vulkan-encode candidate is attempted.
• Compositing itself is GPU (compositor_linux.rs, wgpu/WGSL/Vulkan) — only decode + encode are the CPU-bound stages.
• Contrast with Windows (pipeline_windows.rs): D3D11VA hardware decode + h264_amf hardware encode, zero-copy, no CPU readback between stages.
• The Windows/WGC capture helper already has a working hardware H.264 encode path, so there's a working reference implementation elsewhere in the codebase for the encode side.

Expected/requested

A hardware encode (and ideally decode) path for the Linux export pipeline — VAAPI or Vulkan Video encode — analogous to pipeline_windows.rs's AMF path, so libopenh264/libkvazaar become the fallback rather than the only option, the same pattern already used for Backend::Cpu (lavapipe) vs Backend::Hardware in d3d_linux.rs.

Environment where this was noticed

Linux desktop (AMD), exporting longer screen recordings — export time is disproportionate to recording length compared to what's described for Windows/macOS in technical-documentation/engineering/rendering-performance.md.

[EtienneLescot]

@rafaelvieiras thanks for the report, yes, this is a known limitation. We will work on that as soon as possible.