ok thanks. Now I manually adjusted the framerate to 29,97 what actually reduces the speed of the video, but the two balls in the video/ picture remain. Does this mean that the time dependent measures will still not be fine? If yes, could you help me out how to correct the distortion in Kinovea? As I want to measure the precision of the kick I think I need to correct the distortion.

Again, thank you very much for your help!

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.

Perfect! I sent you a video by mail!

Hi Joan,

thank you so much für your fast reply. Actually, the wrong coordinate system was the problem and after setting the origin on the right place, it now works fine!
Now, I have another question concerning the execution speed of the videos. Unfortunately, after converting the videos, they are played twice as fast as normally. This is only the case when opening the videos in Kinovea, but not when opening the videoy with the VLC player?

I am again very thankful for any kind of help concerning this problem!

I have problems with the function of the markers when using the calibrated perspective grid. When setting the markers, sometimes the coordinates are right and in line with the calibration of the grid, sometimes the coordinates make absolutely no sense. Are there any ideas in which cases this problem might occur?
Before opening the video in Kinovea, I have used GoPro Studio in order to remove the fisheye of a GoPro camera and I have used WinFF in order to converte the .avi-videos (from GoPro Studio) to .mpeg videos (readable in Kinovea). However, I have tried to set the markers in the Original mpeg-Videos (the fisheyed ones) and the problem still exists.

Maybe it might help to have an extract from the kva-file when setting the markers in the calibration grid.

<Calibration>
    <CalibrationPlane>
      <Size>500;200</Size>
      <Quadrilateral>
        <A>428.6288;334.7157</A>
        <B>862.0736;317.8595</B>
        <C>876.5217;486.4214</C>
        <D>431.0368;505.6856</D>

I am very thankful for any ideas concerning a possible solution and I am looking forward to hear from you!