build: patch FFmpeg so that Direct3D 12 decoding works on AMD and Intel

[devopvoid]

Summary

FFmpeg 8.1 cannot decode through Direct3D 12 for long on a driver that needs reference-only allocations (AMD, Intel). In libavcodec/d3d12va_decode.c, get_reference_only_resource() takes a second reference-only resource each time the frame pool hands out a texture it already has one for. Nothing frees the extra, and prepare_reference_only_resources() then gives the decoder the older one as the reference. The decoder fails with No space for new Reference frame! after as many pictures as it has reference slots (10 for VP9, 18 for H.264), and before that it can decode against a stale reference. The map is also allocated with max_num_ref + 1 entries while every loop over it stops at max_num_ref.

Since the media player tries Direct3D 12 first (#326), hardware decoding fell back to software for every stream on an AMD Radeon RX 9070 XT, and 8 cases of HardwareDecodingTest failed where hardware is required.

patches/0001-d3d12va-reuse-the-reference-only-resource-of-a-texture.patch makes a texture keep the resource it has and makes the loops cover the whole map.

How the build uses it

• dependencies/ffmpeg/CMakeLists.txt applies every patches/*.patch, in the order of their names, to the submodule for the length of the FFmpeg build and takes them off again afterwards, whether or not the build worked. The submodule is clean after a build.
• A patch that does not apply stops the build and says so. That is how a bump of FFmpeg shows that the fix has arrived and the patch can go. If an earlier build was cut short, a patch that is applied already is recognised.
• The name and SHA-256 of each patch are part of components.txt, so an install built without a patch, or with another version of it, is built again.
• The CI cache key and restore-key of the FFmpeg cache include patches/*.patch.
• patches/README.md describes how patches are made and kept.

The patch is applied on every platform, though it only matters on Windows, which means the first CI run rebuilds FFmpeg once on all of them.

The fix is not in FFmpeg upstream as far as I know. It should go there too; I have not done that.

Test plan

• Default install on the AMD machine rebuilt by itself (built with other components, rebuilding), the patch was applied, and the submodule was clean afterwards
• Media module suite with -Dwebrtc.test.hardwareDecoding=true, Direct3D 12 first: 76 tests, 0 failures (the 8 HardwareDecodingTest cases that fail on main pass)
• A standalone decode of a 14315 frame 1080p H.264 stream, and of every test asset, runs to the end on Direct3D 12
• A second patch that does not apply stops the build with a clear message, and the first one is taken off again
• A patch that is applied already is recognised, and the submodule is clean after the build