Consider enabling `msmpeg4v3` and `wmv3` decoders (legacy MS video in old MKV/AVI rips)

[cmcpherson274]

The curated decoder list in build.sh (--disable-decoders + explicit enables) covers the
modern set plus mpeg2video/mpeg4/vc1 for the legacy tail. Two adjacent legacy codecs
are absent and still appear in older libraries:

• msmpeg4v3 (MS-MPEG4 v3 / "DivX 3.11") — common in pre-2005 AVI rips. A client that
  claims MPEG-4-family support and routes such a file to the engine gets
  avcodec_find_decoder = nil → VideoDecoderError.unsupportedCodec(id: 16) at load.
• wmv3 (WMV9) — the VC-1 sibling; --enable-decoder=vc1 does not register the separate
  wmv3 decoder, so .wmv-era MKV remuxes fail the same way while plain VC-1 works.

Both are native libavcodec decoders under FFmpeg's LGPL-2.1-or-later terms and require no
external library or GPL flag. In FFmpeg n8.1.2, wmv3_decoder_select="vc1_decoder" (already
enabled), while msmpeg4v3_decoder_select="msmpeg4dec" reuses the already-selected
H.263/MPEG-video core but adds the MSMPEG4 decoder objects. I have not measured the
XCFramework size delta, but it should be modest.

Happy to test a build. For context: we hit the msmpeg4v3 case on a real library item while
running a format-matrix sweep against AetherEngine 6.21.0 (87868c1c), which resolves
FFmpegBuild 2.4.2 (35f393fd). The wmv3 gap is build/source evidence rather than a
fixture repro; our library does not currently have a WMV3 sample. Our client now excludes
both codecs from the engine's claimed envelope, so this is a nice-to-have for coverage
parity with libVLC-class players rather than a defect report.

[superuser404notfound]

Both are in, and the family around them: msmpeg4v1, msmpeg4v2, msmpeg4v3, wmv1, wmv2, wmv3. Shipped as FFmpegBuild 2.4.3, pulled into AetherEngine 6.27.0.

Enabling only the two reported would have left the same shape one file away, since msmpeg4v1/v2/v3 and wmv1/wmv2 all select msmpeg4dec and wmv3 selects the vc1_decoder that was already enabled, so the siblings cost their decoder structs and wmv2dsp and nothing else.

Size, since you asked and had no way to measure it: 32 KB per arm64 device slice.

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%)

Decoder count 40 to 46. Nothing else in the build changed.

Measured, not reasoned. Your msmpeg4v3 case reproduces exactly as you described it, and wmv3 turned out to be testable after all. Before, on 2.4.2:

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

After:

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

Fixtures: msmpeg4v3 in AVI and in Matroska, plus msmpeg4v2, wmv1 and wmv2 in AVI, all encoded with ffmpeg (-c:v msmpeg4 and friends), and for wmv3, which has no encoder anywhere, a real WMV9 Main stream from samples.ffmpeg.org/V-codecs/WMV9/b52crash2.wmv remuxed -c:v copy into Matroska with mp3 audio.

Two side notes from that run. samples.ffmpeg.org/V-codecs/WMV9/wmv3.avi looks like the obvious fixture and is not one: it carries no sequence header, so a full stock ffmpeg fails it too ("Error while opening decoder: Invalid data found when processing input"). And none of these six decoders supports frame threading, so they open threads=1 where mpeg4 opens threads=8. Irrelevant for the content that actually carries them, which is SD, but worth knowing before someone reads it as a regression.

One boundary drawn deliberately, and it is the half of wmv3 you did not ask about. The asf demuxer and the wmav1 / wmav2 decoders are still out, so wmv3 covers WMV9 inside Matroska and MPEG-TS, where the container's own demuxer supplies the stream, and a native .wmv / .asf file still fails at avformat_open_input. That is not an oversight. A native .wmv needs all three, and half the set is worse than none: with the demuxer but no WMA decoder, AudioCodecCompat.from maps the unrecognised id to .unsupported and the session drops to video-only, so the file plays silently. A silent file reads as a playback bug; today's unsupportedCodec is at least an honest one. The avi demuxer, by contrast, was already enabled, which is why your msmpeg4v3 case is complete with the decoder alone.

So: do you have a native .wmv / .asf case in the field, or is Matroska the shape you actually see? If the former, asf + wmav1 + wmav2 go in together as one change and the engine gets the matching audio-route entry in the same release. Happy to do it, it just needs to be the whole set.

Thanks for the report, and for separating the fixture-backed half from the source-evidence half. That is what made it cheap to answer.