6.27.0 - The legacy Microsoft video tail

One bundled-FFmpeg change and its documentation. No engine source change beyond the pin and a routing test, no API change, drop-in from 6.26.0.

Six codecs that routed correctly and then had nothing to decode them

A pre-2005 AVI rip carrying MS-MPEG4 v3 (the codec everyone knew as "DivX 3.11") reached SoftwareVideoDecoder and stopped there:

[AetherEngine] dispatch: codec=16 → software
LOAD FAILED: unsupportedCodec(id: 16)

The routing was right. Since FFmpegBuild#1 the default for every codec the native path does not carry is the software path, so nothing here needed inverting. What was missing sat one layer down: the FFmpeg build's --enable-decoder= allowlist named mpeg4 and vc1 but not their Microsoft variants, so avcodec_find_decoder returned nil and the load failed at the last possible moment. wmv3 (WMV9) had the same gap for the same reason: --enable-decoder=vc1 does not register the separate wmv3 decoder, so plain VC-1 worked and its sibling did not.

FFmpegBuild 2.4.3, which this release pins, adds all six: msmpeg4v1, msmpeg4v2, msmpeg4v3, wmv1, wmv2, wmv3. Only two were reported, but the family moves together, since msmpeg4v1/v2/v3 and wmv1/wmv2 all select msmpeg4dec and wmv3 selects the vc1_decoder that was already enabled. The whole set costs 32 KB on an arm64 device slice.

What now plays

MS-MPEG4 v1 / v2 / v3 and WMV1 / WMV2 wherever a supported container carries them, AVI included, since the avi demuxer was already in the build. WMV3 covers WMV9 inside Matroska and MPEG-TS, where the container's own demuxer supplies the stream.

Measured with aetherctl play on real media: msmpeg4v3 in AVI and in Matroska, msmpeg4v2, wmv1 and wmv2 in AVI, and, for wmv3, which no encoder anywhere produces, a real WMV9 Main stream remuxed -c:v copy into Matroska.

[SWDecoder] Opened: 640x480, codec=msmpeg4, threads=1, 8-bit   → state=ended
[SWDecoder] Opened: 320x240, codec=wmv3, threads=1, 8-bit      → plays through

None of the six supports frame threading, so they decode single-threaded where mpeg4 opens eight threads. The content that carries them is SD, so this is a note rather than a limit.

What still does not play, on purpose

A native .wmv / .asf file. It fails at avformat_open_input, because the build carries neither the asf demuxer nor a WMA decoder, and that set has to move as one. With the demuxer but no WMA decoder, AudioCodecCompat maps the unrecognised audio id to .unsupported and the session drops to video-only, so the file would play silently. A silent file reads as a playback bug; an unsupported-format error is at least honest about what happened. If a real .wmv case turns up in the field, asf plus wmav1 / wmav2 plus the matching audio-route entry ship together.

Reported by @cmcpherson274 in FFmpegBuild#3.