Fix native memory corruption when frame stepping runs concurrently with seeks (ShowFrameNext/Prev vs Seek task)

[dderoia]

Summary

Running frame stepping (ShowFrameNext / ShowFramePrev / ShowFrame) while a seek's decoder work is still in flight corrupts native FFmpeg state. With 3+ Player instances stepping right after accurate seeks (a multi-angle review app), stock v3.10.4 crashes within seconds, 100% reproducibly — AccessViolationException in avcodec_send_packet or av_read_frame, heap corruption 0xC0000374, or fail-fast 0xC0000409. This PR fixes the two races behind it. Likely the root cause of #431 (rapid ShowFrameNext/SeekBackward jog-wheel crashes) and related to #457 (rapid seek crashes).

Both races are already acknowledged in the library's own comments — this isn't a speculative change:

VideoDecoder.cs: * Missing locks (e.g. GetFrameNext) ... Currently no issues as we use locks at higher level
DecoderContext.GetVideoFrame: // TBR: Between seek and GetVideoFrame lockCodecCtx is lost ... (Currently ensure you pause VideDecoder before seek)

The "locks at higher level" assumption doesn't hold: the seek task runs outside Player.lockActions.

Race 1 — seek task vs step path on the same AVCodecContext

Player.Seek (private) does its decoder work (decoder.PauseDecoders → decoder.Seek → decoder.GetVideoFrame → avcodec_send_packet) on a Task.Run background task that holds no player-level lock. ShowFrame/ShowFrameNext/ShowFramePrev hold lockActions — which the seek task never takes — and call decoder.Flush() / VideoDecoder.GetFrame/GetFrameNext (which take no internal locks). Result: one thread flushes/decodes on the codec context while another is inside avcodec_send_packet on the same context → AV / heap corruption.

Fix: a new DecoderContext.StepSeekLock serializes the seek task's decoder section against the three step methods.

Why a new outermost lock instead of reusing the existing ones: the internal lock orders are already inverted between the two sides of the seek path — DecoderContext.Seek takes lockCodecCtx → lockFmtCtx, while GetVideoFrame takes lockFmtCtx → lockCodecCtx (safe today only because both run sequentially on the seek task). Composing either order into the step path from a different thread would introduce a lock-order deadlock. StepSeekLock is therefore always the outermost lock in both paths and never nests the existing locks in a new order.

SeekCompleted is deliberately raised outside the lock, so a subscriber that calls back into a lockActions-taking player API can't deadlock against a step holding lockActions while waiting for StepSeekLock.

Race 2 — demuxer thread vs GetFrameNext on the same fmtCtx (and the same packet field)

GetNextPacket documents "Demuxer must not be running", and GetFrame enforces it (demuxer.Pause(); Pause();) — but GetFrameNext never did. After any seek, VideoDemuxer.Start() leaves the demuxer thread filling queues; a subsequent ShowFrameNext that misses the vFrames queue calls GetFrameNext → GetNextPacket → av_read_frame(fmtCtx, packet) concurrently with the demuxer thread's own av_read_frame — on the same fmtCtx and writing into the demuxer's single packet field. This was the second crash signature (AV in av_read_frame inside Demuxer.RunInternal) that surfaced once Race 1 was fixed.

Fix: GetFrameNext now pauses demuxer + decoder first, exactly as GetFrame always did.

Reproduction

3–4 Player instances on the same local 1080p60 file, paused, then ShowFrameNext issued to all instances repeatedly right after SeekAccurate calls (the pattern of a multi-angle app stepping a synced group, or #431's 10 Hz jog wheel). Stock v3.10.4: crash within seconds, every run, with the signatures above. Two instances never reproduce it — at that load the seek task's decoder work completes in ~0.6 s, before the first step arrives; at four instances seeks take ~1.2 s and the windows stay open. The tile count only widens the race windows; the races themselves are per-instance.

Verification

With this patch, the previously 100%-crashing matrix passes: 3 and 4 instances, steps issued back-to-back and 100 ms-paced, plus stress bursts (60 rapid steps, alternating +1/-1, step/seek interleaving) — 23 probe runs (~1,400 native steps) and 3 stress runs, all clean, with frame-exact step landings verified by pixel comparison against a burned-in frame counter (round trips return to the exact tick and a 0-diff frame; all instances land the identical frame).

One honest caveat: a single unreproduced 0xC0000005 occurred in an early patched run (1 in ~26 runs; never again in 23 subsequent targeted attempts). If something remains, the render-frame lifetime path (vFrames dispose vs in-flight present) is the un-ruled-out suspect — this patch doesn't touch it. The two races fixed here account for every reproducible crash and both captured stacks.

[dderoia]

▎ Added: a second fix in the same seek path (commit 836add3). GetVideoFrame (the accurate-seek path) returns as soon as av_read_frame hits EOF, leaving the codec's delay pipeline undrained — so an accurate seek targeting a stream's final frame presents nothing, while CurTime and SeekCompleted both report success. The frame-step path already drains at EOF (DecodeFrameNext); this gives the seek path the same ability via a null avcodec_send_packet, receiving the tail under GetVideoFrame's existing half-frame acceptance test. Reproduction: SeekAccurate to the last frame of any file — the picture never changes. Verified on 25 fps and 60 fps content by comparing rendered output against ffmpeg-extracted final frames.