[kalopsia-space]

Choosing NVIDIA, AMD or Intel as the encoder in Settings dropped every other encoder, including the LGPL software ones. If that vendor's encoder could not open (NVENC without the host CUDA/libnvidia-encode libraries, or the Intel preference, which only has h264_qsv in the pinned FFmpeg and needs a oneVPL runtime), the engine retried three times and capture ended with BACKEND_FAILED. docs/linux.md already promised a software fallback; it only existed for Auto.

Change

• The vendor preference now narrows the hardware candidates only; the software encoder for the chosen codec is tried last (libopenh264 / libkvazaar / libsvtav1…).
• The candidate builder is exposed as fthr::EncoderCandidates and pinned by a new CTest, linux_encoder_candidates. It fails without the fix (the NVIDIA case asserts) and passes with it.
• docs/linux.md and docs/engine-startup.md describe the Linux behaviour; the Windows paragraph is unchanged (Windows still requires a hardware backend). Unreleased release-notes entry added.

Verification

• Engine built locally with gcc 16 against the pinned FFmpeg: no warnings, 21/21 CTests pass (20 existing + the new one).

[kalopsia-space]

Closing in favour of the 2.0.0-alpha encoder policy. Upstream 2.0 drops automatic software fallback on Windows and makes software an explicit choice (Encoder → Software); the 2.0 UI reports a software codec under a hardware preference as "hardware encoding unavailable", so the user is told and can pick Software rather than silently running on the CPU. The Linux engine will follow that contract in the 2.0 catch-up, which also corrects the docs/linux.md sentence that promised a fallback.