Different frame numbers after trim and vertical shift

Processing long movie with Artemis HQ 1080p>4k.
Saving frames to jpg files.
Processed 1-66049 frames.
Then calculated trim using my program and resumed processing.
New frames started from 65968 and going…
Then I’v started to look how to join them.
And found that in second part same frame as 66049 is now 66050.
And another strange thing is that these frames are not 100% same. Not only in bits but also how they look (66050 looks like shifted vertically by 1 or 2 lines).
Check it out: NotSame.zip - Google Drive

I’v ended processing with 3 parts.
2nd part end have same frame number as in 3rd part (no frame number issue).
But it is also not 100% same (shifted also vertically).

Before I was able to find join point by comparing images hashes. Looks like now it will not work.
Source is in mkv container.


  • The frame number can be slightly mismatched when using trim since we use the time to go to the frame and FFmpeg’s seek to that frame may not be always 100% accurate. Generally, ffmpeg goes to the nearest keyframe.
  • Artemis is a recurrent model which means the output frame depends on the previous frames. So, for the same frame, results could be different if the model sees a different number of previous frames. For example, if the model processes 100 frames vs 10 frames previously to reach the exact same frame, the results could be slightly different.

Ok. I understand. But it should not move image vertically? Even considering it starts from different frames. I does not look like different work of DNN. More likely like wrong fields weaving or so.


It could be the jpeg compression. I would suggest exporting to tiff/png and having some overlapping frames between the 1st part and 2nd part. Discard the overlapping frames from the 2nd part.