joan wrote:@cmdi035: I have seen this effect with some H.264 encoded content, is it your case? I don't have a solution at the moment. The images themselves should be in the correct order but the timestamps are all mangled which is why the cursors jumps back and forth, and why there are issues with seeking.
I'm a bit late, but I have found the problem with the h264 encoded content and the jumping cursor. The jumping cursor occurs when the h264 file contains b-frames. This type of frames needs for its decoding the previous and the following frame (en.wikipedia.org/wiki/Video_compression_picture_types#Bi-directional_predicted_frames.2Fslices_.28B-frames.2Fslices.29 and https://en.wikipedia.org/wiki/Group_of_pictures). If you want to decode a b-frame you first have to decode the following frame, so the timeline will jump forward to the timestamp of the following frame and then back to the timestamp of the b-frame.
To see if your video contains b-frames download the ffmpeg binary (win: ffmpeg.zeranoe.com/builds) and test it with ffprobe (
ffprobe.exe -show_frames videofilename.mp4 > outputfile.txt
). The outfile.txt contains informations about all frames of the video, so choose a small testclip or you get a huge txt-file :-) If you search in the file for "pict_type=B", you will find all b-frames.
You can avoid the problem, if you encode your h264 video without the b-frame feature (ffmpeg cmd switch: -b 0). Then the timeline will work properly, but your filesize will increase.
But I don't understand why the video never stops and repeats and why at the end of the video the velocity fades to 0.
@joan Fixing the problem of the "never ending video" would help a lot, because the usage of b-frames seems to be very common in h264 files.