2.4.3 - legacy Microsoft video decoders (MS-MPEG4 v1/v2/v3, WMV1/2/3)

Adds the legacy Microsoft video decoders to the FFmpeg configure allowlist and rebuilds every slice. Decoder count goes from 40 to 46; the demuxer, parser, filter and bitstream-filter lists are unchanged.

Reported by @cmcpherson274 in #3.

Added

• msmpeg4v1, msmpeg4v2, msmpeg4v3, wmv1, wmv2, wmv3. MS-MPEG4 v3 ("DivX 3.11") is what pre-2005 AVI rips carry, and wmv3 is WMV9, the VC-1 sibling that --enable-decoder=vc1 does not register. FFmpeg has always shipped all six; they were simply absent from this build's allowlist, so such a file demuxed correctly and then had nothing to decode it. Verified in the generated libavcodec/codec_list.c of every slice (&ff_msmpeg4v1_decoder through &ff_wmv3_decoder), which is the reliable check: the release frameworks are stripped, so nm reports nothing either way.

Only the two reported were asked for, but the family goes in together: msmpeg4v1/v2/v3 and wmv1/wmv2 all select msmpeg4dec, and wmv3 selects the vc1_decoder that was already enabled, so once v3 is in, its siblings cost their decoder structs and wmv2dsp. All six are native libavcodec decoders under FFmpeg's LGPL-2.1-or-later terms: no external library, no GPL flag, no patent pool beyond what the existing MPEG-4 Part 2 and VC-1 decoders already imply.

Size

32 KB on an arm64 device slice, which is the number the report asked for and could not measure:

Slice	Libavcodec before	after	delta
tvos-arm64	5,160,096	5,193,184	+33,088 (+0.64%)
ios-arm64	5,130,304	5,163,200	+32,896 (+0.64%)
xros-arm64	5,179,456	5,212,352	+32,896 (+0.64%)
macos / simulator (2 archs)	11,045,440	11,127,488	+82,048 (+0.74%)

All six FFmpeg libraries change in this release, not only Libavcodec: --enable-optimizations bakes the configure line into every library's *_configuration(), and that line now carries the six new flags. The Libdav1d, Libzimg and Libzvbi frameworks are untouched.

What is deliberately still missing

The asf demuxer and the wmav1 / wmav2 decoders. wmv3 here covers WMV9 inside Matroska and MPEG-TS, where the container's own demuxer supplies the stream; a native .wmv / .asf file still fails at avformat_open_input with AVERROR_INVALIDDATA. That set moves as one or not at all: with the demuxer but no WMA decoder, such a file would play video with silent audio, and a silent file reads as a playback bug where an unsupported-format error is at least honest. The avi demuxer, by contrast, was already enabled, which is why the MS-MPEG4 v3 case is complete with the decoder alone.

Note for consumers

The routing side needed no change this time. Since FFmpegBuild#1 AetherEngine's default is the software path for every codec the native path does not carry, so these sources already routed correctly and failed one step later, at avcodec_find_decoder. Measured with aetherctl play on real media, before:

[AetherEngine] dispatch: codec=16 → software
LOAD FAILED: unsupportedCodec(id: 16)          # msmpeg4v3, AVI
[AetherEngine] dispatch: codec=71 → software
LOAD FAILED: unsupportedCodec(id: 71)          # wmv3, Matroska

and after:

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

Fixtures were msmpeg4v3 in AVI and in Matroska plus msmpeg4v2, wmv1 and wmv2 in AVI, all encoded with ffmpeg, and for wmv3, which no encoder anywhere produces, a real WMV9 Main stream (samples.ffmpeg.org/V-codecs/WMV9/b52crash2.wmv) remuxed -c:v copy into Matroska. Note that the obvious-looking wmv3.avi in that same sample directory carries no sequence header and fails to open on a full stock ffmpeg too, so it is not a usable fixture.

One honest caveat: none of these six decoders supports frame threading, so they open threads=1 where mpeg4 opens threads=8. The content that carries them is SD, so this is a note rather than a limit.