feat: decode HEVC and AV1 in hardware in the media player

[devopvoid]

Summary

The media player decoded only H.264 and VP9 on the GPU. This adds HEVC and AV1:

• FFmpeg is built with the hardware decoders of HEVC and AV1: Direct3D 11 and 12 on Windows, NVDEC on Linux, VideoToolbox on macOS.
• FFmpeg's own AV1 decoder has no software path, so AV1 gets dav1d 1.5.4 as its software decoder. It is a new submodule, built with Meson before FFmpeg into a static library that is linked into libavcodec. Its licence and a notice go into the platform jar. On Windows it is built with the static C runtime, which is the one FFmpeg is built with.
• FFmpeg prefers libdav1d to its native AV1 decoder, and only the native one has hardware configurations. VideoDecoder therefore picks a decoder that has one when hardware decoding is asked for, and otherwise keeps the preferred one.
• dav1d's version and options are recorded in components.txt, so changing them rebuilds FFmpeg on its own.
• Meson and Ninja are new build prerequisites. The CI preparation steps install them; the README and the docs say so.

HEVC in hardware only, never in software

HEVC is now decoded on the hardware only. The player sends it to the hardware decoder whether or not hardwareDecoding is set, so isHardwareDecoding() is always true for it. Without a hardware decoder for HEVC, creating the player fails with an IOException ("Decoder not found"). If the hardware does not take a stream, or fails while playing, playback stops with an error. Every path that could reach software is closed in VideoDecoder: software open, a software pixel format in get_format, and the fallback after a hardware failure. Other codecs keep their software fallback.

• FFmpeg's hevc decoder can't be left out where HEVC is decoded in hardware: every HEVC hwaccel runs inside it (configure selects it), parsing the parameter sets and slice headers and handing each slice to the hardware. It never decodes a picture itself. The explicit --enable-decoder=hevc is gone, so the decoder only comes in through the hwaccels. Windows, macOS and Linux x64/ARM64 are unchanged (CONFIG_HEVC_DECODER is still 1 on Windows), and 32-bit ARM Linux, which has no HEVC hwaccel, now ships no HEVC decoder at all.
• The root NOTICE and the FFmpeg notice in each media platform jar carry an HEVC/H.265 disclaimer. It says HEVC is decoded through hardware acceleration only and no software HEVC encoder is bundled. It also says that the jars that decode HEVC in hardware (all but 32-bit ARM Linux) contain FFmpeg's HEVC decoder for that reason, and it leaves the HEVC license to end-users and distributors. The compiled WebRTC library has no HEVC decoder (only libavcodec's table of HEVC profile names, checked on Windows).
• The docs (media-files.md, the MediaPlayer and MediaFileSource Javadoc) describe the new behaviour.

Also: G.711 in Matroska recordings

MediaRecorder left PCMU and PCMA tracks out of .mkv files with a warning, although the docs, the error message and a code comment all say Matroska holds every codec WebRTC sends. Matroska has no codec ID of its own for G.711, so avformat_query_codec says no. The Matroska muxer writes it all the same, in its compatibility mode for Windows audio codecs (A_MS/ACM with a WAVEFORMATEX), which is what ffmpeg -c copy produces too. RecorderTrack's CanHold now lets G.711 into Matroska; WebM is unchanged. The recording guide notes that players built on FFmpeg read this mode and some others do not.

Testing

On Windows x64 (AMD Radeon RX 9070 XT), with the hardware decoders required (webrtc.test.hardwareDecoding and the new webrtc.test.hardwareAv1Decoding), all 81 tests of the media module pass. HardwareDecodingTest now compares every frame decoded in hardware with the software decoder for HEVC and AV1, at 320x240 and 1080p (four new test assets of 19 to 362 KB).

With HEVC hardware only, there is no software decoding to compare HEVC with, so HardwareDecodingTest compares it with luma checksums that FFmpeg's software decoder gave before the change (media-test-hevc*.luma.txt; HEVC decoding is exact, so every conforming decoder matches them). A new test fault, HardwareFault.hideDevices(), makes any machine look as if it had no GPU decoder, so CI runs the case too: HEVC does not open, and H.264 still falls back to software. Each HEVC test also checks that no software decoder was opened. All 88 media module tests pass on Windows x64 with hardware required and none skipped, before and after FFmpeg was rebuilt without --enable-decoder=hevc. With HEVC allowed back into software, the four tests of the hardware-only behaviour fail.

For G.711, TestCall can now send the call's audio in a chosen codec, and two new tests (recordsMuLawIntoMatroska, recordsALawIntoMatroska) record PCMU and PCMA into .mkv and read them back as pcm_mulaw/pcm_alaw at 8 kHz mono. All 9 MediaRecorderTest tests pass on Windows x64, and with the CanHold change undone both new tests fail with the old "cannot hold" warning.

Not verified

Only windows-x86_64 has been built. The Meson cross files for the other targets (Linux x64/ARM64/ARM32, macOS x86-64 and ARM64, Windows ARM64) are generated from the toolchain files and the variables FFmpeg is configured with, but have not been run. The CI builds are the first to exercise them. 10-bit and other profiles were not tested, nor were streams other than the synthetic test assets. G.711 recordings in Matroska were checked by reading them back through FFmpeg, not in other players. That the 32-bit ARM Linux build has no HEVC decoder follows from FFmpeg's configure logic, but has not been built; neither has HEVC hardware decoding on macOS or Linux, where it now has no software fallback.