Skip to content

ffmpeg: build from master (71403a21b0) instead of 9.0 - #51

Merged
jcelerier merged 1 commit into
masterfrom
update/ffmpeg-master
Oct 19, 2026
Merged

ffmpeg: build from master (71403a21b0) instead of 9.0#51
jcelerier merged 1 commit into
masterfrom
update/ffmpeg-master

Conversation

@jcelerier

@jcelerier jcelerier commented Oct 19, 2026 •
edited
Loading

Copy link
Copy Markdown
Member

Moves the SDK's FFmpeg from 9.0 to master, pinned at 71403a21b0 (2026-10-19).

The reason is the Vulkan compute ProRes decoder. In 9.0.x it gets part of every frame wrong, and score refuses Vulkan for ProRes because of that (isVulkanComputeCodec gate, ossia/score@42f0e4374e). Master fixed it on 2026-09-20 (9a69dc787d vulkan/prores_idct: clip values to maximum allowed range, 8cf5b8b0b3 vulkan_prores: undo quant matrix permutation, 1b5041c785 vulkan: keep the iDCT scale factors separable). None of these are on the release/9.0 branch. Companion score PR re-enabling the decoder: ossia/score#2355.

Changes

  • common/versions.sh: FFMPEG_COMMIT pins the commit; FFMPEG_VERSION is derived from it (git-71403a21b0) and stays the source directory name.

  • common/clone-ffmpeg.sh, WASM/ffmpeg.sh: fetch archive/$FFMPEG_COMMIT.tar.gz when it is set, the tag otherwise, and write FF_VERSION so the build doesn't report N-unknown. The ossia mirror is still tried first; it just won't have this one.

  • 0001-rpi.patch rebased. I applied it to n9.0, cherry-picked it onto master, and resolved six conflicts:

    • master's new hevc_nvdec_cuarray hwaccel (and libcurl) sit on the lines the v4l2request entries anchored on, so both are kept;
    • in set_sps(), master now drops the old VPS only after the new arrays exist; that's kept after the patch's if (!hwaccel) block.

    The tests/ hunks are dropped, as the patch header already said they were (they only register rpi_sand with checkasm/fate). Applies to a pristine checkout with no fuzz.

  • Linux/ffmpeg.sh, MSYS/ffmpeg.sh: also assert CONFIG_PRORES_VULKAN_HWACCEL and CONFIG_FFV1_VULKAN_HWACCEL. Like the Vulkan filters, configure drops them silently without a SPIR-V compiler.

Dependency minimums in master's configure are the same as in 9.0 (vulkan ≥ 1.4.317, ffnvcodec ≥ 12.1.14.0, libplacebo ≥ 7.351.0), so the pinned headers and libraries still fit. Master's configure accepts every flag of every ffmpeg-features set (linux x86_64/aarch64, macos x86_64/aarch64, mingw, wasm), plus the options the platform scripts add.

Heads-up: master's last libavcodec bump (0ec6a0872d, IMM6 decoder) set the minor version from 20 to 2 (meant 21), so this build reports lavc 63.2.101. score's version check accounts for it.

Tested (linux-x86_64, Arch, Intel Arc ARL on Mesa 26.2.4 ANV + RTX 5090 on NVIDIA 615.78)

  • Rebased patch. Master + rebased patch configures and builds clean as shared libraries with --enable-vulkan --glslc=glslang and the aarch64 feature set forced on (--enable-sand --enable-v4l2-request --enable-v4l2-m2m --enable-libdrm --enable-libudev --enable-libv4l2). That compiles the patched V4L2 request files; -no_cvt_hw is present. Not built: the actual SDK media stages on any CI platform, linux-aarch64 (where the NEON sand code compiles), Windows, WASM.
  • Vulkan vs software decode, same files, 30 frames. I compared -hwaccel vulkan -hwaccel_output_format vulkan + hwdownload against the software decoder. The hwdownload path errors out instead of silently falling back. "Gross" means off by more than 1/16 of full scale. Intel and NVIDIA gave identical numbers in every row.
file 9.0.2 max / gross master max / gross
FATE Sequence_1 ProRes 422 Proxy 147 / 0.096% 1 / 0
FATE Sequence_1 ProRes 422 LT 88 / 0.046% 1 / 0
FATE Sequence_1 ProRes 422 67 / 0 1 / 0
FATE Sequence_1 ProRes 422 HQ 4 / 0 1 / 0
FATE Sequence_1 ProRes with Alpha (4444, 16-bit alpha) 1 / 0 1 / 0
FATE gray.mov 18 / 0 1 / 0
generated ProRes std / 4444 81 / 0.003%, 4 / 0 1 / 0, 1 / 0
re-encoded 422 HQ / 4444 / 4444+alpha / 4444 XQ at 1920×1080, 1920×1088, 1888×1062 — 1 / 0 for all 12
generated FFV1 yuv420p / bgr0 0 / 0, — 0 / 0, 0 / 0

Two cases left on master, both reported to score in its PR:

  • prores-odd.mov (322×178, neither dimension a multiple of 16): up to 161 off in the chroma of the bottom-right partial macroblock, 72 samples over 30 frames. This is a decoder bug; 1888×1062 is clean.
  • FATE prores4444_with_transparency.mov has a MOV clean aperture (1920×1080 coded, 1888×1062 shown). Uncropped, Vulkan matches software (max 1 / alpha exact). Cropped, the hardware frame ends up cropped at top offset 8 instead of 9. That's the crop path, not the decoder.

🤖 Generated with Claude Code

@jcelerier @claude
ffmpeg: build from master (71403a21b0) instead of 9.0
11e3fac 
9.0.x ships the Vulkan compute ProRes decoder that gets part of every frame
wrong: up to 147 code values off, ~0.1% of the samples of the FATE ProRes 422
files, on Intel ANV and NVIDIA alike -- score refuses Vulkan for ProRes because
of it. Master fixed it on 2026-09-20 and now matches the software decoder to
+-1 on the same files, so pin master by commit until a release carries it.

- versions.sh: FFMPEG_COMMIT, with FFMPEG_VERSION derived from it; clone-ffmpeg.sh
  and WASM/ffmpeg.sh fetch that commit's archive and write FF_VERSION, so the
  build reports git-71403a21b0 rather than N-unknown.
- 0001-rpi.patch rebased onto master. Its tests/ hunks are dropped, as its
  header already claimed they were.
- Linux and MSYS assert the ProRes and FFV1 Vulkan hwaccels are configured, the
  way they assert the Vulkan filters: configure drops them silently without a
  SPIR-V compiler.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@jcelerier jcelerier mentioned this pull request Oct 19, 2026
Merged
@jcelerier
jcelerier merged commit b48b31b into master Oct 19, 2026
0 of 8 checks passed
@jcelerier jcelerier mentioned this pull request Oct 27, 2026
Merged
jcelerier added a commit that referenced this pull request Oct 28, 2026
@jcelerier @claude
msys: install ffmpeg with V=1
ab9ca3e 
Since ffmpeg 33d5616fbe (after 9.0, so since #51 moved us to master), a
non-verbose install prints each file with its own printf, all chained into
one shell command per library. libavutil's ~100 headers make that command
~13-17k characters and it reaches sh truncated: both Windows media jobs fail
in install-libavutil-headers ("unexpected EOF while looking for matching
`"'" on x86_64, Error 127 on arm64), on master since 2026-10-19 as well.
With V=1 the recipe is one `install -m 644 <files> <dir>`, ~3k characters.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JeL19ofVgPe9u9q7J1V9ex
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@jcelerier