Skip embedded cover art when opening audio files

Thomas Portalrequested to merge
OursCodeur/openmw:audio-art-shims into master

Depends on !5490 (merged)

libavformat always parses attached pictures and neither demuxer exposes a skip option, meaning a file with embedded cover art reads the picture on every open, on the thread that starts the sound.

Real case: The Lossless Soundtrack (Nexus 59121) embeds ~4.3MB of art in each of 21 FLAC tracks; every track change reads 4.3MB today, costing a 4.4s stall on emulated slow media, found during other audio-perf related work.

The MR changes : two shims in FFmpegDecoder's stream setup, applied via content sniffing at open; the file on disk is untouched.

  • for id3v2 the 10-byte tag header carries a syncsafe size; the stream is windowed past the tag, so the demuxer never sees it, art included. Seeks and reported size offset accordingly.
  • for FLAC metadata block headers are 4 bytes (is-last bit, 7-bit type, 24-bit length), checksum-free. The header chain is walked at open; PICTURE headers are served with type relabelled to PADDING, and the demuxer seeks past the payload unread.

OpenMW reads no tags or artwork from audio files, so nothing consumes what the shims hide. I also couldn't find any audio-artwork related mod on Nexus that would miss this.

With the patch : cover-art mp3 init read 2,851,868 -> 16,512 bytes (-99.4%); 1.15MB-picture FLAC 1,151,961 -> 32,768 (-97.2%). The Lossless Soundtrack's own tracks: p50 73.7KB / max 98.3KB per open, almost 60x cut (vanilla Morrowind's mp3s have no art in the files).

In-engine, via FUSE latency injection (open 30ms, read 8ms, direct_io, page cache excluded): avformat_open_input: real 4.3MB-art FLAC 4365ms -> 25ms; synthetic art-mp3/art-FLAC also 25ms.

Mislabelled files (flac data named .mp3) still work: the sniff is content-based; the probed fallback from !5490 (merged) handles demuxer choice.

Merge request reports