Preview one frame behind and trimmed encodes shifted on many MP4/MOV/TS sources (decoder repeats the first frame after a seek) #157
Description
Reported on the videohelp forum (thread 419911, post #152): with every processing filter disabled, the preview's Processed frame lags the Original by one frame.
Cause
The worker's source decoders write rawvideo, so ffmpeg uses constant-frame-rate output timing. The preview decoder (always) and the encode decoder (when the job is trimmed) seek to (first − 0.5)/fps, so the first frame they keep arrives half a frame after the seek point. For some time bases ffmpeg fills that gap by emitting the first frame twice: every later frame lands one slot late, and -frames:v N drops the last.
Decoding 8 frames from source frame 40 (indices identified by MD5 against a sequential decode, ffmpeg 9.0, deps 1.16.0):
| Source (time base, rate) | Today | With setpts=PTS-STARTPTS |
|---|---|---|
small_clip.mp4 (1/2997, 29.97) |
40, 40, 41 … 46 | 40 … 47 |
| 29.97 ProRes MOV, time base 1/11988 | 40, 40, 41 … 46 | 40 … 47 |
interlaced_test.avi (1/25), colorize_test.mp4 (1/12288, 24) |
correct | correct |
Effects
- Preview: on an affected source the Processed side shows frame N−1 while the Original shows N.
- Trimmed encodes: a trim of frames 100–109 came out as
100, 100, 101 … 108: first frame doubled, last frame lost, picture one frame late against the audio. Untrimmed encodes don't seek and are unaffected. - Detectors:
--detect-noise-halodecodes frame pairs with the same seek, so on an affected source every pair can be one frame twice and noise is under-reported. Crop and native-resolution detection measure a neighbouring frame.
No existing test caught it because preview and encode shift identically, and the frame-mapping fixture has an unaffected time base.
Fix
Rebase timestamps after the seek (setpts=PTS-STARTPTS at the front of the decoder's one -vf), only when the decoder seeks, and test seek alignment against an independent sequential decode.
Activity