MacGameVideoFix 4.7.6 — both architectures staged, and NINJA GAIDEN 4 measured on stable

NINJA GAIDEN 4, on the engine this project supports

The gate change shipped in 4.7.4 has now been run on CrossOver 26.3 with D3DMetal 3.0, and the log says something better than "it works": MFTEnumEx answers 1 for H.264 there, so the original path carried it and the new fallback never ran. That is what made the change safe to ship before it was measured — it only reaches for "any video decoder" where the old code was already returning zero — and it is now measured rather than reasoned. The source reader opens the .msd, and no ActivateObject line follows on either engine: the game counts what it is handed and never activates it.

Both architectures, in one pass

CrossOver 27 runs ARM Windows binaries as well as x86_64 ones, and a bottle records which it is — "WineArch" = "arm64" against "win64". The two do not share a plugin directory, and staging only x86_64 left an ARM bottle with no VC-1, WMV or WMA decoder at all. The GStreamer framework is universal, so the material had been there the whole time; the gap was the script's.

stage-codecs.sh now stages every architecture an engine ships, in one pass, and each bottle gets the staging its own WineArch asks for.

Two things that had to be got right rather than assumed:

• lib64 is the old single-architecture layout, and it holds x86_64. The fallback to it happens only when staging x86_64; taking it for aarch64 would have filled an ARM directory with x86_64 libraries that resolve while staging and fail on load.
• An ARM bottle recorded against an engine with no ARM GStreamer is refused, with the reason. It used to be handed a path built from the engine's name without anyone going to look — and a key that is set, on a bottle that reads as configured, with nothing behind it, is worse than one that is wrong.

Two ways of not claiming what we cannot check

Both found by a status that disagreed with a working game:

• A bottle outside CrossOver's own directory cannot be written to. wine --bottle takes a name, not a path, so two bottles called "Steam" in two roots collapse onto one. They are found — that is useful — and skipped out loud rather than counted as done.
• A bottle that cannot answer is not a bottle that says no. An ARM bottle on a CrossOver with no ARM support has its keys on disk and cannot run reg.exe to confirm them. Each bottle is now asked something that must exist before its answer is trusted.