[ryan-morris]

Why

Renovate bumped nv-codec-headers to SDK 13.1, which raises the minimum NVIDIA driver to 610. FFmpeg's NVENC refuses to open on anything older, so current main has no NVIDIA encoding for:

• any machine not yet on driver 610;
• Maxwell, Pascal and Volta cards (GTX 900/10-series) permanently, because the 580 driver branch is the last one that supports them.

Holds also had no review mechanism: nothing ever prompted a revisit, so a pinned dependency could stagnate silently.

What

nv-codec held on the 13.0 line (driver 570+). Tracking issue: #54.

• Pin n13.0.19.1.
• Renovate is capped to /^n13\.0\./, so 13.0.x patch releases still arrive.
• The rule uses explicit four-component versioning. The default semver-coerced scheme drops the build number, so n13.0.19.2 would never have been offered.
• Both FFmpeg lines accept ffnvcodec >= 12.1.14.0. The 13.1-only paths are behind version guards with fallbacks, so 13.0 drops optional features, not builds.
• The Linux and Windows install docs now state the driver floor.

Holds are now reviewable.

• Each hold has a structured record in deps.json: .defaults.<dep>.hold with allowedVersions, issue, reviewAfter and liftWhen.
• ledger-validate.sh checks the record's shape. Holds are allowed only in .defaults, and the date must be a real calendar date.
• New scripts/ci/holds-test.sh keeps deps.json and renovate.json in step: exactly one unconditional rule per hold, the same cap in both files, and the pin inside its own cap. It has fixtures for every failure mode.
• A new review-holds job in the weekly check-updates.yml runs on github.token with issues: write. Once reviewAfter passes it:
  • comments once on the hold's issue;
  • applies hold-review-due until a human lifts the hold or sets a new date;
  • reopens the issue if it was closed while the hold is still in place;
  • clears stale labels from lifted holds.
• It never lifts a hold or moves a date itself.
• The mbedTLS hold (mbedTLS held at 3.x: FFmpeg has no mbedTLS 4 support #18) gets the same record. Its rationale is corrected: SRT and librist consume mbedTLS here, not FFmpeg's TLS layer.

Verification

Real hardware A/B: FFmpeg 9.0.2 cross-built for win-x64 (NVENC only), on an RTX 3080 with Windows driver 591.86:

headers	h264_nvenc	hevc_nvenc
13.1 (main)	Driver does not support the required nvenc API version. Required: 13.1 Found: 13.0 / minimum required Nvidia driver for nvenc is 610.00	same
13.0 (this PR)	1080p encode OK, ~7.3×	1080p encode OK, ~7.3×

Green CI alone does not prove this: the hardware probes record an old driver as a NOTE, not a failure.

Gates: all 11 ledger and Renovate gates pass, including renovate-config-test against renovate@44.134.3. shellcheck is clean.

review-holds dry runs: checked before and after the review date, with a lifted hold, two holds sharing one issue, a moved date, and a missing or malformed ledger.

Codex: approved the plan with changes; all were applied. Codex's code review returned "ship with fixes", and both findings are fixed in the second commit.

Touches deps.json, so CI builds both FFmpeg lines (8.1.3, 9.0.2), and merging cuts a release.

🤖 Generated with Claude Code

[ryan-morris]

Superseded by #60: the hold carries over as pin: { nvenc: '13.0' } in ffmpeg-build.yml (nv-codec-headers 13.0.19.1, 13.0.x patches still arrive), with the driver floor in the docs. #54 stays open as the hold's tracking issue.