Thanks for your help. Now, the file is also speed up both in VLC and Kinovea, in both players with 59.93982fps. Actually, I think that this is the right resolution as we have chosen 720p/60 as resolution mode in GoPro. Thus, as you said, it actually might be a problem of the converter and we are trying to solve this possible interlacing problem in the prgoramming of the converter at the moment (I think this might be a problem despite using a p-mode).
However, I am wondering whether the fastened speed in Kinovea actually causes a problem for our data analysis. Maybe you have an idea on that when I briefly describe what we want to measure: In this scientific study, we want, among other variables, measure the speed of football penalty shots during 3 time periods: In the first part of the kick (the time when the ball leaves the foot till 5 clicks later when setting the time in Kinovea on milliseconds), in the last part of the kick (when the ball hits the goal line till 5 klicks less) and the hole average speed for the kick. This is why we want to set the markers in this standardized points and then we manually want to calculate the speed during the mentioned intervalls as we know how much time passes between two klicks. Now I am wondering whether the fastened speed changes the time interval for one klick? And may this also be concerned with the fact that when speed is fastened,when clicking from one frame to another, there are two balls visible?
I know, that for measuring speed, there is also this tracking option in Kinovea. When testing this, we had the impression that it is not very precise and sometimes the tracking doesn't work. Might this also be due to the fact that the camera is not high enough above ground? The thing is, that when publishing our data, we have to be very precise in describing how we measured speed. This is one reason why I was struggeling to use the tracking option.