1

When I open two video files that need to be synced, one plays at a slightly faster speed than the other. This problem is consistent whether using play or next frame navigation buttons. Approximately 20 seconds into the videos, they are 3 seconds off. This difference becomes exponentially worse at later time points in the videos.

I have tried using Kinovea with two different versions (0.8.15 and Kinovea-0.8.26-x64) on two different computers, one running Windows 7, the other running Windows 10. I've tried closing and reopening files in Kinovea with no luck.

When I open both videos in Video Pad, I am able to sync them with minimal mismatching (+/- one frame, consistent rate over time with no exponential increase). However, Video Pad is much less user friendly and I would prefer to use Kinovea as it offers better features for our purposes.

Videos were both recorded in 640x480 with NCH Debut Video Capture software at 30 fps. I have confirmed that capture speed rates do not differ when watching live recordings.

2

Thanks for the report.

If you open the two videos but invert the screens they are loaded in, does the desynchronization go in the same direction or in the opposite direction?

It's possible that the right screen gets less CPU time but 640x480@30 shouldn't be an issue. Do you see the right video lagging behind?

What happens if you open the same video twice and sync it, does one of them also drift compared to the other?

3 (edited by cmo5 2017-11-15 19:33:47)

The speed issue the same regardless of whether it is on the right or left-hand side of the screen. (That is, the speed of one file is consistently faster than the other, even when their placements are inverted.) When I open two files that are the same, the speed issue is no longer present. They run at the exact same speed.

4

Forgot to ask, do you mean the content/action seen in the video is off but the timestamps are in sync, or do the timestamps diverge as well?

5

Both videos were recorded with a hh:mm:ss:ms text time stamp embedded into the video using NCH Debut Video Capture software. Interestingly, both the time stamp according to Kinova and the embedded time stamp in the video footage are off. One video is always progressing faster.

6

To get the complete picture, what is the FPS value read by Kinovea? This is visible in the info bar above the video. Also please confirm that both videos are at 100% playback speed and the value of checkbox in Preferences > Playback > General > "Link speed sliders when comparing videos". Also the value in menu Video > Configure video timing > High speed camera > Capture framerate. Although these options did not exist in 0.8.15 so it's unlikely the culprit.

The timestamps in Kinovea should not diverge, that definitely smells like a bug somewhere. What happens when you click a random location in the common navigation bar at the bottom?

The way it's supposed to work is that the common time position is computed first and then it is mapped to each individual video and they are adjusted accordingly. What you describe would be an issue in the time mapping for this particular video, but it's especially strange if they are coming from the same capture software.

Do you have a way to check if this video is playing back at the expected speed when it's played alone in its own screen?

7

The speed read by Kinovea is 30 fps for both videos. I cannot find the option to "Link speed sliders when comparing videos" in the Preferences tab in the 0.8.15 version. Both videos are in 100% speed.

If I click a random location, it goes to the correct point in both video files with no issue. I cannot play or move forward frame by frame at the same rate in both videos, however. Either form of navigation results in one video moving faster than the other. For example, from time 0:00:00:00, when synchronizing both videos at this time point, advancing one frame results in Kinovea time stamps of 0:00:00:03 and 0:00:00:03, respectively. Additional frame by frame navigation time stamps are as follows:

0:00:00:06 and 0:00:00:06
0:00:00:13 and 0:00:00:10
0:00:00:16 and 0:00:00:13
0:00:00:20 and 0:00:00:16
0:00:00:23 and 0:00:00:20
0:00:00:30 and 0:00:00:23
0:00:00:33 and 0:00:00:26

You can see that the first video is moving faster. However, it does not matter which video is on the left or right.

If opening one video, the video that is playing faster appears to play faster than actual seconds in Kinovea, though it is difficult to confirm this.

8

Hypothesis: the file on the left has non constant framerate. The capture application set a custom timestamp to each frame as it was capturing them. Marked the final file as 30fps but in reality using non-constant intervals between the frames. And there might have been frame drops during the capture process, so some frames/timestamps are missing, and the resulting video is faster than expected.

Variable framerate is pretty rare and not supported in Kinovea, but the timestamp is nonetheless read from the metadata associated with the frame, so this could explain the behavior. 

Do you have a small example of such file that you could send me (joan at kinovea dot org) or upload somewhere, to verify that hypothesis?

What happens to the timestamps when you read this file on its own? Do they also progress in a non-constant fashion? Note that you can set the time format to "total milliseconds" to make it easier to experiment maybe.

9

I think your hypothesis is correct. When I switched to total milliseconds, the faster video progresses as follows:

33
67
100
133
200
233
267
333

Some frames appear to have been dropped when creating the video file. While I am bummed that this is not supported in Kinovea, I appreciate you taking the time to identify the issue. Thank you!

10

OK.
When you do the capture, whether in NCH Debut Video or in Kinovea, try to have almost nothing else running on the computer so the compression on the fly has more chances to sustain the framerate. Also, try to set the capture file target on an SSD if possible, it will also decrease chances of frame drops. If your camera supports MJPEG streams, doing the capture in Kinovea might give the best performance as it will store the frames coming straight from the camera without decompression/recompression.