A transport stream seeks to whichever packet precedes the target, not
to a keyframe, so after a seek the decoder dropped everything up to the
next keyframe: a trimmed load began late or, on a clip with a single
keyframe, found no frames at all, and the preview showed and reported
a later frame than the one asked for - frame 0 included, since a seek
to the stream's own start lands past its first keyframe.
decode_from checks the first frame out of a seek and, when it lands
after the target, seeks again from further back and from the top last.
Load Video, the clip decode and the frame previews all seek through it.
Trim windows, frame indices and preview times count from the video's
first frame (frame i at i / fps), but the decoders compared them with
the file's own timestamps. A video stream that starts late - about
1.4 s into a transport stream, after an MP4 edit list's delay, or
behind leading audio - lost frames from every window, reported shifted
frame indices that the editor wrote back into frame_index, and cut its
audio out of sync.
stream_seconds moves a decoded time onto the video clock and every
decode, preview, storyboard and audio cut now goes through it. The
metadata duration falls back to the stream's own length rather than
the container's, a late audio track is padded with silence up to its
first sample, and core's VIDEO trim is shifted onto the file's
timestamps.
ausboss