[capibawa]

What and why

This is split out of #957, as offered in its closing comment. The scope is still open in #927, so this PR is there to show the change concretely: rework or close it according to what's decided there.

VideoToolbox decodes AV1 only in hardware (Apple M3 and A17 Pro and later). On older chips, main gives black pictures with a red line. But Fire Emblem Fortune's Weave's movie module aborts on a decoder that does not initialize (movie::detail::InitializeDecoderByTransferMemory, subsdk2+0xf9b4), so there is no error path for the game to take.

Two commits:

1. dav1d 1.5.4, vendored unmodified: the arm64 sources and NEON assembly, with meson's config.h for an arm64 Apple target and per-bit-depth wrappers. dm/third_party/dav1d/README.md lists what's compiled. This is about 81,000 lines, all upstream code (BSD 2-Clause), byte-identical to the 1.5.4 tag.

2. dav1d as a second backend in hle_movie_av1.c, behind main's interface. It is used:

   • on chips with no hardware decoder;
   • for a stream VideoToolbox refuses;
   • with DM_AV1_DAV1D=1, on any chip.

   Its planar pictures are handed over as NV12. 10- and 12-bit streams are shifted to 8 bits, and a stream with no colour matrix gets BT.601 below 720 lines and BT.709 from there, as VideoToolbox does. hle_codec_video.c drops the black-picture path and keeps a full-range stream's range. dm/host/Makefile builds gen/dav1d/libdav1d.a, and the iOS build picks it up from the Makefile's compile lines.

Checked

• Tests and builds:
  • make -C dm/host/tests GAME=010015100B514000 run. t_codec_video now decodes a 64x64 AV1 key frame on VideoToolbox and on dav1d, and reads both back as the same NV12 (AddressSanitizer and UBSan).
  • make -C dm/host GAME=04007EF01F8AE000 dmhost builds.
  • dm/ios/tools/compile_check.py passes (258 files, dav1d's among them).
  • test_docs passes.
• Games, Fire Emblem Fortune's Weave (04007EF01F8AE000, v131072):
  • With DM_AV1_DAV1D=1 on an M3 Pro, the opening movie (2560x1440) decodes through dav1d with no red line.
  • On this branch, with shader libraries built for main's chain version, I took screenshots of the opening movie decoded by dav1d and by VideoToolbox: the same pictures and colours, differing only where smoke moves between frames.
  • On Fire Emblem Fortune's Weave plays on the Mac #957's branch, VideoToolbox and dav1d gave the same pictures, bit for bit, over the opening's first 600 (about 450 pictures a second each).
  • A tester's M1 Pro played the first two movies through dav1d, smooth and in sync (#927).
• Devices and OS: MacBook Pro M3 Pro, macOS 27.0.1. iOS: compile check only.
• regress.py: not run. Only AV1 decoding changes, and no game in the local harness has AV1 movies.
• clang-tidy isn't installed here, so CI's lint is the check for the new C code.

Docs

• The movies.md entry, the game's note, development.md and env_switches.tsv (DM_AV1_DAV1D) describe it; python3 dm/tools/docs_symptoms.py was run (no change to the index)
• No game files, keys or data extracted from a game in the change or the attachments (the test's AV1 frame is a synthetic red one from SVT-AV1)

Related: #927.

🤖 Generated with Claude Code

[seedds]

Thank you. This landed on main as bd41cf7 (dav1d vendored) and 65501fb (its use), with you credited as co-author on both. I'm closing the PR because the commits were rebased rather than merged here. The maintainer decided the scope question from #927: vendoring dav1d is accepted, and the iOS build keeps it too.

Changed from your branch:

• black_i420 moved into t_codec_video.c, the only place still using it.
• The n_threads comment now says two task threads decode while the submitting thread waits, as dav1d_decode_frame does with n_fc 1.
• The commit message no longer says the game could not get past its movies on those chips. main initialized the decoder and gave black pictures there, so the abort you found only applies if Initialize is refused.

Checked on an M6, macOS 27.2:

• The 130 upstream files are byte-identical to a fresh download of VideoLAN's 1.5.4 archive.
• VideoToolbox has no software path here: with the hardware decoder forbidden, a session opens for H.264 but not for AV1 (-12906).
• The first 300 pictures of each of the game's 82 movies went through hle_movie_av1.c on both decoders. All 23,219 pictures had the same size, matrix, range and hashes (every 7th row hashed), and no stream was refused.
• With DM_AV1_DAV1D=1 and no window, the game plays the opening's 3,301 pictures, right on screen, and goes on into the prologue with no crash. That's the on-screen check your PR couldn't do.
• t_codec_video passes.

Still unchecked:

• This exact code on a chip without hardware AV1. Only your earlier version has run on one, in the M1 Pro test on AV1 movies for SDK 22 games: VideoToolbox where the chip has it, vendored dav1d elsewhere (scope before a PR) #927.
• iOS beyond the compile check.
• The frame rate on M1 and M2 at the higher render size, the point you raised on AV1 movies for SDK 22 games: VideoToolbox where the chip has it, vendored dav1d elsewhere (scope before a PR) #927.

clang-tidy failed on this PR over t_geometry_hazards.m, which it doesn't touch, and lint-c was already failing on main. Some of the PR's other checks were still pending at the push.