Problem with rewinding video in ffmpeg 7.1.0

[Jamaika1]

I use:
be6c204
mpeg5/xeve@954ed6e

Assertion failed: 0, file xevdm_picman.c, line 529sq= 0B

[dariusz-f]

You mean FFmpeg 7.0.1 "Dijkstra" or master HEAD?

[Jamaika1]

FFmpeg/FFmpeg@262168b
https://github.com/FFmpeg/FFmpeg/releases/tag/n7.1-dev
https://www.nasm.us/pub/nasm/snapshots/20240727/win64/

https://www.sendspace.com/file/yvyxkj

[dariusz-f]

Problem confirmed on Official FFmpeg 7.0.1 (0e09f6d690b748f61d652ad58ed96c2d48670110) with:

• mpeg5/xeve@954ed6e
• be6c204

Opening EVC video using ffplay works but when seeking video using RMB generate errors:

Seek to 55% ( 0:00:02) of total duration ( 0:00:05) B
Last message repeated 1 times
[evc @ 0x7f2928733370] Failed to decode bitstream sq= 0B
Last message repeated 85 times

[Jamaika1]

So it is normal.

[dariusz-f]

Problem with seeking exists, so this issue have to be opened until we fix it.

[kpchoi]

Root-caused this. It is primarily an FFmpeg wrapper problem, with a robustness gap on the library side.

Primary cause — FFmpeg's libxevd.c has no .flush callback. When you seek, avcodec_flush_buffers() does nothing to the xevd instance, so the decoder keeps its pre-seek DPB state (pending-output pictures, expected output POC) and then gets fed access units from a different position. Reproduced outside FFmpeg by feeding a forward jump without any reset:

• Open-GOP stream (xeve default; the only IDR is the first frame), main profile: after the jump every subsequent AU fails to decode and the decoder never recovers — in a debug build this is the xevdm_picman.c assert you hit (no free picture buffer / broken reference state).
• Closed-GOP stream, jumping exactly to a later IDR: decodes fine with zero errors — the library recovers by itself at IDR boundaries.
• Closed-GOP stream, jumping mid-GOP: two AUs fail, then it self-recovers at the next IDR.

So the fix belongs in FFmpeg: the wrapper's flush callback should tear down and recreate the decoder (xevd_delete + xevd_create), like other stateless-flush wrappers do. Note also that seeking a raw .evc stream is byte-position seeking, which lands mid-GOP; with an open-GOP encode there is no later IDR to recover at, which makes the raw-file case especially bad — seeking a container (mp4) that seeks to sync samples behaves much better.

On the xevd side there is a secondary hardening item we may take separately: when the DPB has no free buffer the picture manager asserts / wedges permanently instead of failing recoverably (e.g. force-bumping the oldest pending picture).