Search options (Page 103 of 137)

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.

Thanks
It is indeed probably the same issue as bug 220 but another variation. When the saving dialog box is closed, the screen try to refresh itself and the image is used from two different places at the same time (display and record).
To validate this hypothesis, you may try to relocate the saving dialog box somewhere not directly above any of the images, before clicking save, if it's possible.
I'll open a new bug to track this.

Edit: created bug 227.

Bonjour,

Hum, je pense que ceci est une anomalie. Je créerai un rapport de bug dessus.
Le problème se produit il me semble quand la taille de l'image est plus grande que l'espace disponible dans l'écran de lecture.
Du coup l'image est réduite en taille, et les indicateurs de vitesses sont réduits de façon proportionnelle, sans qu'ils ne soient limités.
(edit : bug 230)

Pour avoir une taille en mètres, il faut « calibrer » l'image. Ajouter une ligne quelque part sur un objet de taille connue et indiquer sa taille manuellement. Sinon, le logiciel n'a aucun moyen de faire le rapport entre les pixels et une unité réelle.
Voir l'aide à l'article « Utiliser Kinovea > Mesurer > Mesurer des vitesses ».

You might do this by launching Kinovea from the command line and passing arguments.
Unfortunately, I don't think this is documented anywhere, not even in the manual, although it has been there for a while now

To launch a file directly, and at 75% speed you can do this at the command line:

> kinovea.exe -file test.mpg -speed 75

Here is the missing doc:
Usage:
[-file <path>] [-speed <0-200>] [-noexp] [-stretch]

-file: complete path of a video to launch; default: 'unknown'
-speed: percentage of original speed to play the video; default: 100.
-stretch: The video will be expanded to the screen size; default: false.
-noexp: The file explorer will not be visible; default: false.

Exemples:
1. > kinovea.exe -file test.mkv -speed 50
2. > kinovea.exe -file test.mkv -stretch -noexp

To do this you need to run Kinovea directly from cmd.exe, from a .bat script or from another program that support running shell commands.

Are you referring to tracking a player during a whole match ?
The tracking fuction is intended to track joints or small objects. Speed measurement on it will only work in very controlled situations. (perpendicularity, line calibration, etc.)

Currently this is not possible and not to be expected in the foreseeable future.

The main reason is that some of the main usages include saving with drawings painted on which need recoding. When muxing to AVI, not all codec would be available, also, depending on codec, not all framerate are possible, which would mean yet another case for saving with slow motion.

It was initially trying not to reencode if not needed, but it proved too much of a hassle to maintain.
It's a bit of a shame but it's currently the only maintainable solution for me…