Search options (Page 96 of 131)

Hi,
The feature has been added in one of the experimental version. You can get the lastest at the top of this sub forum.
The "dual save" button is in the lower right corner, next to the common position slider.
Please report success or failure, as someone has reported an issue with the function here.

Hi,
There is still much work to do in the player itself and limited resources, so the perimeter of the application has to be focused.

I understand how important it might be in your workflow but the ammount of work and the shift in the software focus has to be balanced against the number of persons needing this integrated in the player (as opposed to using a third party application).

I'd rather see Kinovea develop as a player with great analysis capabilities, rather than a file management system.

Since working with files is probably something completely independant, maybe you can find a management system that suits you and just use Kinovea to play the files.
If this external management system is open in its interfaces, maybe we can work out a way to display its data from within Kinovea, or even interact with these.

Thanks for your understanding. Do not hesitate to report your findings regarding these dedicated management systems.

Ah, yes. 0.8.7 has a not very verbose log level…
Please do the following:
- Go to the directory where you installed Kinovea, and open the file "logConf.xml".
- Look for the word "INFO" in capitals, and replace it with "DEBUG". (line should be: <level value="DEBUG"/>)
- Restart Kinovea, open the file, and check the log.

Note that the log file rolls over itself each time you open Kinovea, so you have to open it (or refresh it) after you actually open the video.

I'm confident that the 25fps vs 50fps is coming from interlaced fields in the file, but would have to see the log to confirm.
Experimental version 0.8.11 will also trace more infos in this regard, if it's possible.

Yes but how did you know the video was 25fps? Is it a setting on the camcorder, info from another software like MediaInfo, etc. ?

A bug was fixed in the experimental versions recently to take this into account, but it will also change the actual play speed by half, so it may not be a viable workaround. (The real fix will be for Kinovea to find and use the proper frame rate of course)

The new menu was also added more recently, but really it's the same as if you right click the image and do "set original speed".

Thanks

It's dependant on the CPU load so it's not linear and can't be corrected manually like this. Sometimes the problem is not there, e.g. if the image size is small, the machine powerful and the capture frame rate low.

The issue is that the rate at which images are grabbed is estimated and used as frame rate for the final video.
However, when the recording starts, the CPU is more heavily used and images come less frequently to the program.
What is needed is to completely decouple the recording from the frame grabbing.

Hi,
First of all thank you for checking this.
It is very important that the results are right and I really appreciate these kind of tests.

Since it is exactly half the speed, the difference is most likely not how we computed the distance, but more likely how we get the frame time interval. My guess is that we get the same distance between points, but one of us use half the time frame interval of the other.

I get the time interval from the information contained in the file. One hypothesis that could explain this behavior is if the file is interlaced and the frame interval used for computations is actually the field interval (50 fields per second vs 25 frames per second). I'll have to double check that.

- How did you get to the 40ms value ?
- Can you post the info that Kinovea reads from the file ? Go to Help > Open log folder… > then open "log.txt" and look for the block of lines between the "--------------" lines.
It should look something like: [File] - Filename : fish.avi, [File] - Size (bytes) : 4024704, [Container] - Name: avi (AVI format), etc.
Post all the block if possible.
- Can you also go to menu Motion > High speed camera and read the fps value in the box. This is most probably what Kinovea is using for computations.

Thanks

Note: Euclidian distance = SQRT((xA - xB)² + (yA - yB)²).

It's also possible that the small difference in time stamps is due to rounding error in the output time representation. For example, a common frame rate is 29.97 fps, this would give time stamps that appear to last a tiny bit longer or shorter than the next, but they average out regularly, the frame rate itself does not change.

Ha! Now this just reminded me of bug 183. The export wouldn't work for some unknown reason, and then start to work again.
Please retry the Excel export. It may have magically fixed itself.

Distance and speed on trajectory are not currently exported.

You are doing it the right way (or at least I do similarly).
The data is not erased when you move back in the video to let you move back and re-adjust only a single point manually without changing the others.