VC-1 software decoder fails with "Picture size 0x0 is invalid" on some post-seek landings, dropping frames

[classicjazz]

What happened?

After a subset of programmatic seeks, a freshly-opened VC-1 decoder context logs a hard decode error instead of the routine "first frame is no keyframe" warning that every other seek produces:

[vc1 @ 0x...] [IMGUTILS @ 0x...] [error] Picture size 0x0 is invalid
[vc1 @ 0x...] [error] Failed to set dimensions 0 0

Each occurrence coincides with a layerDrop jump in the next diagnostic sample (frames are lost, not just delayed). Observed 4 times across 3 sessions: once on progressive 23.976fps content (FileD, after seek to 1237.56s) and 3 times on interlaced 29.97i content (FileF, after seeks to 2125.91s and 1973.56s across two separate sessions of the same episode). It is not specific to the deinterlace path, but occurs more often on interlaced content in this sample.

Steps to reproduce

1. Open a VC-1 (software path) file — reproduces on both a progressive file (FileD) and an interlaced file (FileF).
2. Perform several programmatic seeks to arbitrary timestamps in succession.
3. Watch for [IMGUTILS] Picture size 0x0 is invalid in the log — it doesn't fire on every seek, only some.

AetherEngine version or commit SHA

6.68.0

Host app

AetherPlayer

Platform

macOS

OS version

macOS 27

Device / chip

Mac M1 Studio Max

Playback path

Software (dav1d) host

Source media (for playback bugs)

No response

Error codes / log lines

Anything else

This looks like a more severe version of the same landing condition that produces the ubiquitous "first frame is no keyframe" warning (seeking mid-GOP, before a full reference chain is available) — but here the decoder fails hard enough to report zero dimensions for that frame instead of just warning and continuing. Sample diagnostic context (FileF, second occurrence):

18:05:40.325Z  [vc1 @ 0x7ca2661880] [IMGUTILS @ 0x16dd0db68] [error] Picture size 0x0 is invalid
18:05:40.325Z  [vc1 @ 0x7ca2661880] [error] Failed to set dimensions 0 0

No corresponding corrupt counter increment and no crash — the frame is simply dropped and playback continues. Given it reproduces on both a progressive and an interlaced file, this is likely a general VC-1 reference-picture-buffer edge case on seek landing rather than something deinterlace-specific, but the sample size on interlaced content (3 of 4 occurrences) suggests it's more easily triggered there — possibly because interlaced GOPs land the software decoder on a bad reference frame more often.

[superuser404notfound]

Traced. The context that logs this is not the decoder, it is the VC-1 PARSER, and "freshly-opened" is exactly right: it is freshly opened at every seek, by libavformat, on purpose.

The chain. ff_read_frame_flush runs on every reposition and does av_parser_close(sti->parser); sti->parser = NULL, so each seek gets a genuinely new VC1ParseContext with its VC1Context zeroed. vc1_parser.c never seeds that context from avctx->extradata; only the decoder does that, at init. So on a fresh parser max_coded_width and max_coded_height are 0 until an in-stream sequence header BDU comes past. ff_vc1_decode_entry_point (vc1.c:525) falls back to exactly those two fields when the entry point carries no coded size of its own, and ff_set_dimensions(avctx, 0, 0) then fails with the two lines quoted. The parser ignores the return value, so nothing is thrown away on account of it.

That accounts for "only some seeks" without needing a reference-chain story: it fires when the landing keyframe's BDUs carry an entry point but no sequence header, and stays quiet when a sequence header precedes it, which is a property of the encoder rather than of the seek.

The same uninitialised context does more than log, and that part is measurable. With v.profile still 0 the parser reads an advanced-profile frame header through the simple/main reader, so pict_type and field_order are whatever falls out. libavformat then overwrites the packet's keyframe flag from that (demux.c:1296-1302), and matroskadec forces need_parsing = AVSTREAM_PARSE_HEADERS on every non-HEVC video track (matroskadec.c:3046), so the parser is unavoidably in the path for a Matroska VC-1 remux.

Measured on a WVC1 remux here (Test_1440x576_WVC1_6Mbps.wmv, -c copy to MKV):

ffprobe -select_streams v:0 -show_entries packet=flags        1451 of 1451 packets flagged K
ffprobe -fflags +noparse -select_streams v:0 ... same         10 of 1451 flagged K

Ten is the container truth. The file on disk carries ten key bits and Cues at those same ten timestamps. So the parser is inflating every packet to a keyframe on this track type. Seeking is unaffected, because avformat_seek_file uses the Cues index, which is built before the parser ever runs, but it is a real corruption of the packet flags and it is the same defect that produces the ubiquitous "first frame is no keyframe" warning.

On the frame loss. I would not attribute it to this yet. All four occurrences are at seek landings, and every seek costs frames on this path whether or not the line appears, so the coincidence with a layerDrop step is expected rather than evidence. The per-seek drop rate is worth pursuing on its own terms, which is the other issue.

Where the fix belongs. This is upstream: the VC-1 parser should seed its context from extradata the way the decoder does, and the forced need_parsing on a Matroska VC-1 track is questionable in its own right given the blocks are already frame-aligned. FFmpegBuild carries a small set of local patches for cases like this and already upstreams them, so it is a candidate for both. No date on it, and it is behind the seek-reference fix in priority, since that one is user-visible and this one is a log line plus a flag nobody on this path reads.