Thanks for the sample!
I reproduce the problem right away. Unfortunately at the moment I cannot fix it.
It is a unusual file in the sense that it actually has a variable framerate. Basically inside a video file, in addition to the global framerate, each individual frame has a timestamp. Here the video framerate is set to be 4fps, for 5526 frames (23 minutes). What Kinovea does when asked for the next frame is: 1. decode one frame and display it, 2. check the actual frame timestamp, 3. update the frame position in the timeline. This approach works to correct small variations or non integer frame intervals.
It doesn't work with this kind of videos because there aren't really 5526 individual frames. It might be an encoder optimized for screen capture. When the image doesn't change, no frame is saved in the video at all. Whenever the screen does change though, a frame is stored with the proper timestamp. Thus the sequence of timestamps is highly non linear and depends on the content dynamics. But when Kinovea reads the file back, basically being a constant framerate player, it jumps from frame to frame and eats the time gaps in between, giving a much accelerated result.
