fix(ffmpeg): pin nv-codec-headers to n13.0.19.1 to restore NVENC on legacy driver branches

[MathiasOki]

Description

The nv-codec-headers submodule tracks master and had drifted to n13.1.15.0, which bakes a Driver does not support the required nvenc API version. Required: 13.1 floor into FFmpeg's h264_nvenc/hevc_nvenc at compile time.

NVIDIA's legacy driver branch (580.xx, the last branch supporting Pascal and older GPUs) is frozen at NVENC API 13.0 and can never reach the 610.00+ driver this requires, so NVENC on Linux silently falls back to software encoding on those cards.

This pins the submodule back to n13.0.19.1, the same tag Sunshine already uses for one of its three Windows NVENC SDK builds, restoring NVENC on legacy drivers while keeping current-driver support.

Related to LizardByte/Sunshine#5590, where LizardByte/Sunshine#5451 fixed this for Windows (Sunshine's own D3D11 NVENC path) but not Linux, since Linux NVENC goes through FFmpeg built here rather than Sunshine's own NVENC code. This PR doesn't fully close that issue by itself — Sunshine's third-party/build-deps submodule pointer will also need bumping once this merges.

Note: third-party/FFmpeg/nv-codec-headers is auto-updated by Dependabot on a daily cron with no ignore rule, so without an ignore entry in the central Dependabot config (LizardByte/.github), Dependabot will likely propose bumping this back to n13.1.15.0 or later again.

Screenshot

Issues Fixed or Closed

• Related to NVENC on Linux still broken for Pascal GPUs in v2026.830.223700 — #5451 only fixed Windows Sunshine#5590

Roadmap Issues

Type of Change

• feat: New feature (non-breaking change which adds functionality)
• fix: Bug fix (non-breaking change which fixes an issue)
• docs: Documentation only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semicolons, etc.)
• refactor: Code change that neither fixes a bug nor adds a feature
• perf: Code change that improves performance
• test: Adding missing tests or correcting existing tests
• build: Changes that affect the build system or external dependencies
• ci: Changes to CI configuration files and scripts
• chore: Other changes that don't modify src or test files
• revert: Reverts a previous commit
• BREAKING CHANGE: Introduces a breaking change (can be combined with any type above)

Checklist

• Code follows the style guidelines of this project
• Code has been self-reviewed
• Code has been commented, particularly in hard-to-understand areas
• Code docstring/documentation-blocks for new or existing methods/components have been added or updated
• Unit tests have been added or updated for any new or modified functionality

AI Usage

See our AI usage policy.

• None: No AI tools were used in creating this PR
• Light: AI provided minor assistance (formatting, simple suggestions)
• Moderate: AI helped with code generation or debugging specific parts
• Heavy: AI generated most or all of the code changes

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[ReenigneArcher]

Thank you for the PR submission, but it looks like you used AI to create this PR.

Please read and follow our Contributing guidelines and specifically our AI Usage policy.

Additionally, please update the PR to use the correct template. You can find it at https://github.com/LizardByte/.github/blob/master/.github/pull_request_template.md?plain=1

[MathiasOki]

@ReenigneArcher, Thanks for the note, I updated the description to use the correct template, with the AI Usage section filled in.

[ReenigneArcher]

Thanks for updating that.

I'm not sure about rolling this back though. What do we lose by rolling back? And we certainly cannot stay locked to an old version forever.

Unfortunately I don't think FFmpeg provides a way to dynamically select the SDK like we're doing with our Windows side NVENC encoder on Sunshine's side.

[MathiasOki]

I get the hesitation, and I don't want to come across as pushing an old version just for the sake of it.

To give a bit of context on where I'm coming from: I'm on a Pascal-era card, on the 580.xx driver branch (the last one that supports it), and Sunshine/NVENC is genuinely one of the best pieces of software I'm able to use to play games from my PC to my TV. I wasn't hoping to get an exception forever, but was hoping to have some backwards compatibility running for some time forwards - without trying to hold the project back. I get that staying on the newest and following that often is for the best, but I believe I'm not the only one with old cards - especially now with the GPU prices.

From what I can see, with the help from AI, there are no security issues with allowing this backwards compatibility, but again this type of software is not my strong suit.

Here is some technical review I've done with the help of AI regarding this issue/PR:

---

What does 13.1 actually add, and are we giving any of it up?

I diffed the real headers between n13.0.19.1 and n13.1.15.0 rather than going by the changelog. New in 13.1:

• NV_ENC_BFRAME_REF_MODE_HIERARCHICAL — a new tree-like B-frame reference mode
• Two new RC pic flags: NV_ENC_PIC_FLAG_PREQPDELTAMINQP / PREQPDELTAMAXQP
• HEVC enableRefPicListModification flag
• A few new NVDEC-side async decode APIs
• Windows ARM64 native loading (not relevant to this Linux build)

None of these are used anywhere in the FFmpeg build here today. None of them are security fixes — they're new encoder features gated behind driver/GPU support that only reaches someone already on a driver new enough to report NVENC 13.1, which by definition isn't the legacy-driver users this PR is for. The struct changes are also backward-compatible (new fields land in what used to be reserved padding in 13.0), so nothing regresses for anyone already on current drivers. So as far as I can tell: this pin costs nothing today, for anyone — it's not newest-secure-version vs. old-insecure-version, it's newest-features vs. still-fully-supported.

Why not stay locked forever

Agreed that shouldn't happen by default. A couple of options that could keep it a deliberate, revisitable choice instead of a silent standoff with Dependabot:

1. An ignore rule for third-party/FFmpeg/nv-codec-headers in LizardByte/.github's central Dependabot config, so it stops proposing the bump daily but doesn't block bumping it manually later.
2. A tracking issue documenting why it's pinned, so whenever it's revisited — a security-relevant SDK update, or a feature that actually needs 13.1+ — there's a clear record instead of someone rediscovering the tradeoff from scratch.

On dynamic SDK selection

You're right that FFmpeg doesn't support that the way Sunshine's Windows NVENC path does. It's a hard, unconditional check in FFmpeg itself (libavcodec/nvenc.c, nvenc_load_libraries):

if ((NVENCAPI_MAJOR_VERSION << 4 | NVENCAPI_MINOR_VERSION) > nvenc_max_ver) {
    // "Driver does not support the required nvenc API version"
}

It compares the compiled header version against what the driver reports and refuses to load if the driver is older, regardless of whether the features actually used would've worked fine. That's an upstream FFmpeg limitation, not something build-deps or nv-codec-headers can route around — so the header pin is genuinely the available fix here, not a shortcut around a better one.

[thx1111]

I'm on Arch with a GM107 GPU and would also like to see a fix. Though compiling with pkgver=2026.516.143833 and git checkout n8.1.2 will avoid the Driver does not support the required nvenc API version. Required: 13.1 issue, it still fails to fix an underlying problem:

Warning: [h264_nvenc @ 0x56444c52f440] Multiple reference frames are not supported by the device
Error: [h264_nvenc @ 0x56444c52f440] Provided device doesn't support required NVENC features
Error: Could not open codec [h264_nvenc]: Function not implemented
...
Error: RGBA_to_NV12 failed: cudaErrorNoKernelImageForDevice:no kernel image is available for execution on the device
Info: Encoder [nvenc] failed

[ReenigneArcher]

I'm going to look into a custom patch for FFmpeg that allows dynamic SDK selection like we do on Windows. I think that's a better approach long term, than locking to an old driver.