I experience a problem with synchronization of two videos. When I run them long enough, there is a time code difference between two videos that grows for as long as I play both videos. I calculated that there is, for my videos at least, an error in speed of about 0.4% between videos speed. Not much, but accumulating over time, so after a few minutes, time code difference is quite noticeable. I would like to know if it would be complicated to have video time code synchronization, instead of video speed synchronization. Synchronization would be more precise for long videos.
- joan
- Admin
- Offline
I would like to understand whether it's a bug or not first.
The way it is supposed to work is that there is a global time defined outside of both videos and the synchronization ensures that each video local time maps to the current global time. Normally they should not diverge. At most, if the videos have different framerates not multiple of each other one of them might slightly oscillate between being late or early relatively to the other.
There is a dual cursor in the common navigation bar at the bottom. Does it diverge over time?
What are the framerates of each video? (you can see this from the high speed camera menu).
(Assuming version 0.8.24)
I have two "identical" videos to compare, one running at 25 Fps and other one running at 29.97 Fps. I run them in synchronized mode from same start frame and look at time code for both of them. After 5 minutes, first one gives 5:00,16, second one gives 04:59,83, a difference of 0.1%. After 10 minutes, first one gives 10:00,28, second one gives 09:59,66, a difference still at 0.1%. After 15 minutes, first one gives 15:00,36, second one gives 14:59,43, still a difference of 0.1%. I made sure Kinovea was the only software running. I did not get the same result as the first attempt I made to compare my two videos. But it seems time codes do not evolve at same rate. It is possible this is caused by difference in frame rate. This is not a problem when comparing short videos. But it can become uncomfortable comparing long videos. This is the reason I proposed to see if it was possible to synchronize on time code instead of speed. I already spotted a few differences between my two videos thanks to Kinovea, which was the only software I found able to do synchronized viewing.
- joan
- Admin
- Offline
Unless I misunderstand what you mean, I think synchronizing on time codes is the same as what is currently done. The global time is converted to video-local times (to account for the synchronization point which is zero in your case I presume) and then converted to a video-local timestamp to reach the correct frame.
What you describe could be caused by a rounding error somewhere. I will try to reproduce the problem.
Do you have the same effect when you manually set the common time (click/drag inside the common frame tracker)?
There could indeed be an issue with the fact that the playback timer has a granularity of 1ms which cannot express 29.97fps precisely. I will double check that there is an adjustment to account for that.
- joan
- Admin
- Offline
I reproduce a problem but I'm not sure it's the same.
For me it's the video that is 29.97 fps that is further along the timecodes, not the other way around.
It is running too fast by a bit less than 1% which is the expected error from the rounding issue mentioned earlier.
The issue only occurs during playback itself, as soon as I pause and restart playback the synchronization error is reset to zero. There is no issue when using the common slider to set the common time. It also has no impact on time-dependent computations like chronometer, kinematics, etc.
I ack the problem with timer precision. I'll have to think about the proper way to fix it.