Search options (Page 50 of 136)

Yes the timing information by default depends on the framerate of the video, so time intervals will be wrong. If you know it's wrong and you know the correct framerate, you can fix it in menu Video > Configure video timing > in the bottom pane you will see what Kinovea reads from the file. In your case you can change the value to 29.97 and apply, and the playback speed as well as all time dependent measurements should be correct.

If you can see two balls in just one frame, it could very well suggest that the original footage was indeed interlaced and that it got deinterlaced. When an object moves a lot between the two half-frames the deinterlacing algorithms tend to "reconstruct" the object twice.

To improve the automated tracking you can change the size of the search and object box used by the trajectory tool. For some objects it's best to reduce the "object" window to avoid tracking background. You can also adjust the position of the object manually to get the most control. This will work better with the camera higher above the ground. Then if you go to the trajectory data analysis you can find all the measurements and export them quickly to the clipboard or CSV file. This uses a smoothing pass on the data to minimize the noise introduced by the digitization process. The exact procedure is described in the "About" tab of the data analysis dialog.

Note that you can also correct the distortion of the GoPro directly in Kinovea, it will not undistort the images but it will distort the coordinate system to match the lens. The calibration procedure is not very well documented at the moment though. But in theory it could be more accurate than using the stock de-fishing algorithm of GoPro studio which will use standard values for all devices, whereas here you would calibrate exactly for your camera lens. (Depending on how the sensor is glued on the board the optical axis may not be exactly aligned with the center of the image).

This is only relevant if you are making spatial measurement on the images though, if you just do time measurements because you already know the distance between markers visible on the images I don't think you need to correct the distortion at all.

Thanks for the file. I see that the action is indeed sped up, but I also get the same in VLC and SMPlayer. Kinovea reads the file as 4,989s long, 299 frames, 59.93982fps. VLC also says 59.93982fps. Using VLC 2.26.

Are you sure it's not the pre-processing that introduce this effect?

Did you shoot in 1080p or 1080i in the GoPro? I've read there are issues with the 1080i mode not really being interlaced. Maybe the defisher or converter thinks it's interlaced when it's actually not, and it tries to deinterlace it. This could merge pairs of frames and end up twice as fast as expected.

Hi,
Some issues may arise if the perspective grid is at a very steep angle, as is the case when placing it on the floor seen from a camera that is not very high above ground. Try to stay above 30° or so between the camera axis and the plane. Move the camera higher up and look down if possible.

At a steep angle the coordinates aren't going to be very precise since one pixel in the image will cover a lot of real world area.

Also, the coordinate system origin can be moved independently from the grid, maybe you have moved it inadvertently? If the origin of the coordinate system is outside of view it could yield unexpected results. If it's above the horizon line it is effectively at infinity and things will be completely broken. Once the calibration is active, if you move the grid's corners it's going to move the coordinate system with it.

It's possible to see the actual coordinate system with menu Tools > Coordinate system. If you don't see the origin where you expect it, this should be fixed first. The primary axes are thicker than the other lines and can be dragged around. Move the grid's corners around to make it more rectangular to check where the origin is, and place it where you want relatively to the grid. Then move the grid back to match the real plane.

I added an option to allow multiple instances of Kinovea running at the same time. I'm not 100% sure of the implications of this regarding some file access, but we'll see how it pans out. It will be disabled by default.

The panel containing the capture thumbnails has been rewritten from scratch between 0.8.15 and 0.8.25 so it's possible the issue with dual recording slowing down is fixed already.

What were the other issues that prevented you from using 0.8.25? I remember the ability to record with delay was one and this should be addressed in the next version as well.

Yes, this scenario gets confusing very quickly. To add to the confusion, there is also the "display" framerate, when you change the "speed slider" value. The final framerate of the composite video takes the speed slider value into account. Note that the speed slider value is given with regards to the recording framerate, not the file framerate.

When you have two videos with differing "recording" framerates, you need to be aware of the value of the following setting: Options > Preferences… > Playback > General > Link speed sliders when comparing videos.

If checked this option will force the speed sliders of both videos to use the same value (ex: 50%), which should make them use the same reference time scale. So if you had filmed the same performance with two different cameras at different recording framerate and the cameras output different file framerates the videos should still be synchronized out of the box ( as long as you set the recording framerate).

I think it's easier to think about all this in terms of frame intervals. The inverse of the recording framerate gives the real world duration between the captured moments.

Yes the framerate of the video is a metadata. The default display framerate of the video can be found in Kinovea in the top bar above the player screen or in Video > Configure timing in the bottom panel. In Windows by right clicking the file and going into Properties > Details > Video > Frame rate.

It should not depend on which video is on the left or right.
Each video has its frame interval computed, for the synchronized playback. The common player uses the smallest frame interval to drive the dual video playback. Unless there is a bug, this smallest interval is what should be used in the final composite file.
There is an extra check to limit the interval to 10ms at the smallest, so the final file should never be faster than 100fps. 

You cannot manually specify the output framerate of the composite video at the moment.

You can reopen the composite video in Kinovea and verify frame by frame that everything is there. Maybe it's possible that some combinations of framerates would result in missed frames in one video? Normally since it's driven by the smallest frame interval this shouldn't happen. Instead, the lower frequency video should have duplicated frames.

No the default display framerate of the original videos is no longer present in the final composite video.

If you want to make some experiments you could use the KSV test file format. Here is a KSV file:

<?xml version="1.0" encoding="utf-8"?>
<KinoveaSyntheticVideo>
  <FormatVersion>1.0</FormatVersion>
  <ImageSize>800;800</ImageSize>
  <FramesPerSecond>20</FramesPerSecond>
  <DurationFrames>100</DurationFrames>
  <BackgroundColor>255;128;0;0</BackgroundColor>
  <FrameNumber>true</FrameNumber>
</KinoveaSyntheticVideo>

Copy this in a new text file and save with extension .ksv. Kinovea has special code to interpret this as a video, for testing purposes. You can change the FramesPerSecond field for experimenting. And inside Kinovea you can change the "recording" framerate as if it was a regular video.

Yes, menu Video > Configure video timing > Video. (bottom section).
The value put here will set the framerate value reported by the file in its header, so video players will be "tricked" into playing the video at that framerate. Or, in the case of Vimeo, it should be tricked into not changing the framerate of the video.

This will distort the scale of time when playing back the video. So for example if you were to take a 100fps input video and change this value to 50fps, the live action would be reproduced half as fast as it should. However, step by step operation should correctly visit all the original frames without skips.