5.8.2 - Software fallback for VT-undecodable H.264/HEVC (#2)

Fixed

H.264 / HEVC formats VideoToolbox cannot hardware-decode now fall back to software instead of a black screen (#2).

Some MP4s played in QuickTime but rendered nothing in AetherPlayer and the macOS demo (reported by DrHurt on an Intel Mac mini). H.264 High 4:2:2 / 4:4:4 / High-10 and HEVC Rext are accepted by AVPlayer at the HLS CODECS level, so the item reaches readyToPlay, but on hardware without a VideoToolbox decoder for the profile (Intel Macs, older Apple TV chips) the native path then renders nothing. QuickTime plays the same file via its own software decoder; the native route had no analogous fallback.

Unlike AV1 (gated on VTCapabilityProbe.av1Available), H.264 / HEVC had no per-format hardware-decode gate. This release adds VTCapabilityProbe.canHardwareDecode(codecpar:): it builds the avcC / hvcC format description and tries a require-hardware VTDecompressionSessionCreate. When that fails, the source routes to the SoftwarePlaybackHost (libavcodec), which decodes these profiles and sws_scales them to NV12 / P010 for the renderer. The gate runs at two sites: the load dispatch (VOD, via the pure VideoRoutingPolicy.forcesSoftwareForUndecodableFormat) and the software host's HEVC decoder selection (so an HEVC Rext routed there uses libavcodec rather than failing the HW-only path).

Apple Silicon has hardware decoders for all of these profiles, so the probe returns true and they stay on the native path unchanged (verified: control plus High 10 / 4:2:2 / 4:4:4 and HEVC Rext all dispatch native and play).

707 tests pass.

Full Changelog: 5.8.1...5.8.2