sylph-decoder ed409ded90 re: reproduce the container-seek trap on this disc, and clear the Explorer of it ...

sylpheed-port asked whether my capture or extraction paths seek with -ss before -i.
Reproduced on this disc's own movies: a 4.0 s audio request returns 4.597 s (ADV)
and 4.256 s (S00A), with correlations of -0.03 and -0.34 at zero shift, so the
windows are different content rather than shifted. The 4.597 matches their 4.6.

But the VIDEO seek here is exact -- container-seek frame at 20.0 s is byte-identical
to the frame from a full decode with no seek. So the trap is a property of the audio
stream, not of -ss placement as such.

The Explorer has two -ss sites, both video, and its audio path (decode_audio_wav)
never seeks -- so it is not affected. Read only; the viewer is the human's tool and
was not modified.

My own instrument failed twice first: a vstats line read as a timestamp, then
showinfo reporting frames from before an output-side -ss discard. The pixel
comparison needed no interpretation and settled it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v

2026-08-30 23:36:42 +00:00

3.1 KiB

Raw Blame History

View Raw