Add Intel QSV qsv2404 variant

[fmotalleb]

New ubuntu2404-based image with FFmpeg configured through oneVPL ( --enable-libvpl, FFmpeg >= 6.0 ) and the runtime stack shipped in the image: oneVPL dispatcher ( libvpl2 ), oneVPL GPU implementation ( libmfx-gen1.2 ) and the Intel media driver ( intel-media-va-driver-non-free ), so users only need to attach /dev/dri.

Templates, update.py wiring ( x86_64 only ), generated docker-images for 8.0/8.1/9.0 plus the GH Actions and GitLab matrices are included. The CI smoke test asserts --enable-libvpl and h264_qsv for qsv variants.

oneVPL supports Tiger Lake ( 11th gen ) and newer GPUs only; older GPUs such as Skylake return MFX_ERR_NOT_FOUND from the dispatcher, so the README documents falling back to the vaapi variant there.

[jrottenberg]

Pulled this branch and verified it directly against jrottenberg/ffmpeg (not just the fork's own checks) to get a real signal with full CI permissions, since PR checks from forks run the base branch's build.yml, which wouldn't have exercised this PR's own new QSV smoke-test assertions.

Code review

Structurally consistent with the existing single-variant parents (vaapi2404, nvidia2404):

• Templates mirror vaapi2404 almost exactly (same builder deps + libvpl-dev; runtime installs libvpl2, libmfx-gen1.2, intel-media-va-driver-non-free instead of the VA-API packages).
• update.py wiring is correct: qsv2404 is x86_64-only (X86_ONLY_PLATFORMS), and --enable-libvpl is correctly gated on FFmpeg >= 6.0 (the flag isn't available on older branches).
• Generated docker-images/{8.0,8.1,9.0}/qsv2404/* match what update.py produces from the templates (verified via pre-commit run --all-files) — no hand-edited drift.
• github-actions-matrix.json / gitlab-ci.yml entries for qsv2404 are structurally identical to the vaapi2404 entries.
• README/CONTRIBUTING additions follow existing conventions, including the fallback note for pre-Tiger-Lake GPUs.

CI verification

Ran the actual build+smoke-test for all three FFmpeg versions on this branch: run #36371874851

• 8.1.3-qsv2404: ✅ passed. FFmpeg configured with --enable-libvpl, h264_qsv present, smoke test's own --enable-libvpl/h264_qsv assertions passed.
• 9.0.2-qsv2404: ✅ passed, same checks.
• 8.0.3-qsv2404: ❌ failed, but purely on infra — public.ecr.aws returned 429 Too Many Requests: Data limit exceeded pulling ubuntu:24.04 (AWS Public ECR's anonymous-pull data cap, tripped by bursting ~30 concurrent builds via a manual full-matrix dispatch to test this). Retried and hit the same cap again, so it's a sustained window, not transient — unrelated to this PR's code. Given 8.0.3 uses the exact same template/logic as the two that passed, I'd expect it to build cleanly under normal (non-burst) CI load.

Also surfaced two pre-existing issues on main unrelated to this PR while testing (a lint job that's flaky against live upstream FFmpeg release data, and the ECR data cap above) — tracking those separately, not blockers for this PR.

Overall: looks good to merge.

[fmotalleb]

Closes:
#354 Feature Request: VAAPI QSV support
#374 Unknown encoder 'h264_qsv' when using -vcodec h264_qsv
#146 HEVC_QSV Support from Intel MediaSDK
#438 Request for Intel Media SDK support (libmfx)

[jrottenberg]

Closes: #354 Feature Request: VAAPI QSV support #374 Unknown encoder 'h264_qsv' when using -vcodec h264_qsv #146 HEVC_QSV Support from Intel MediaSDK #438 Request for Intel Media SDK support (libmfx)

Thank you !