Choose an encoder fallback when hardware encoding fails

An encoder name in a capability list does not prove that an encode can run. Driver state, device access and input format can still make a hardware attempt fail. Choose a fallback after observing the actual attempt, and keep the failed output separate from anything presented as a finished export.

Make fallback conditional

This synthetic decision fixture models an unavailable hardware path. It does not invoke a graphics driver or measure encoding speed.

attempts = []
def try_encoder(name):
    attempts.append(name)
    return name == "libx264"

encoder = "h264_nvenc"
if not try_encoder(encoder):
    encoder = "libx264"
    if not try_encoder(encoder):
        raise RuntimeError("Both encoding attempts failed")
assert attempts == ["h264_nvenc", "libx264"]
assert encoder == "libx264"

An application should inspect the actual child-process return code and retain a bounded diagnostic message. Avoid treating every failure as a hardware problem. A missing source file or full output disk will probably fail through both paths, and repeating the same work only delays the useful error.

A failed hardware attempt can trigger a software retry; either successful path still needs output verification.

Preserve a clean output boundary

Write each attempt to a known temporary output owned by that job. Remove or quarantine a failed partial file before retrying. Promote an output to its final name only after the encoder exits successfully and the file passes the required probe checks. The presence of an .mp4 file alone does not establish a complete result.

Software encoding may require different options from the hardware encoder. Keep the output contract stable, such as dimensions, frame rate policy and codec family, while reviewing encoder-specific parameters separately. Do not copy a hardware preset name into a software command and assume it has the same meaning.

Test both failure paths

Use a stub for predictable selection logic, then a generated short media fixture for the software path on the target build. Test cancellation during the first attempt so that the application does not start a fallback after the user has stopped the job. If the software attempt fails too, return a failure state with both attempt categories.

The FFprobe documentation supports inspecting output metadata. ShortForge documents hardware detection and CPU fallback; the fixture here is independent and makes no measured speed claim.