1,426 Reply by joan

(10 replies, posted in Bug reports)

willfig wrote:

Thanks for the info on frame rates.  Data was captured with a logitech web cam (in .wmv format) and also a Panasonic Lumix in AVHCD lite (.mts) format. When I look at time stamps on each frame they don't always appear to have the same time between frames.

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.

willfig wrote:

As for the export issue...I'm using version 0.8.7.  I did save a .kva file and when I open it in notepad there does seem to be some data there.  I've just tried exporting to the text format as well as html and those do seem to work.  Though I swear when I tried them before they didn't.

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.

willfig wrote:

So is the info on speed and/or distance ever output?  I can of course easily calculate that from the coords, just wondering if I'm doing something wrong and not getting it.

Distance and speed on trajectory are not currently exported.

willfig wrote:

when using the tracking if it loses the fish I have been stopping playback, backing the video up either by grabbing the icon on the track or using the back arrow keys (though this very often doesn't work...probably my variable frame rate based on some other posts I read) then deleting all points after the present one and restarting tracking. Is that the only way to do that. I first thought that if I backed the video up the track would also back up, erasing any errant points.

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.

Go to forum: Bug reports

1,427 Reply by joan

(10 replies, posted in Bug reports)

willfig wrote:

Also while I'm asking, I believe both of these files have variable frame rates. In the file above, the time unit between each point is exactly the same.  So I'm wondering, when speeds are calculated, is the variable time from the file used for each frame or is there some assumption made that the time interval is constant?

Variable frame rate is not supported as such. The average framerate is computed from file information and used throughout Kinovea. From what I could gather, variable frame rate files are very rare for regular camcorder and cameras.

About the spreadsheet export, you could try to save to .kva first (from regular save dialog, save analysis data only) and open the result in notepad. In this XML file (Kinovea format), you should see your trajectory data.

If it's not there, the problem is before the export to spreadsheet. If you can see it, the issue is in the spreadsheet export.
In this case, try to export to XHTML or simple text to see if the issue would be specific to the MS-Excel XML export.

Which version are you using ?

Go to forum: Bug reports

1,428 Reply by joan

(14 replies, posted in Bug reports)

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.

Go to forum: Bug reports

1,429 Reply by joan

(3 replies, posted in Français)

Bonjour,
Notez que pour l'instant la fonction capture est assez expérimentale.

Au niveau caméra, c'est un peu compliqué car les nouvelles caméras n'ont pas d'option de streaming.
Il faut passer soit par un boîtier de conversion analogique -> numérique et utiliser la sortie analogique du camescope, soit utiliser une caméra DV ou HDV avec un port FireWire (IEEE1394), soit effectivement une webcam.

En réalité je n'ai pas trop d'expérience là dessus donc si d'autres utilisateurs pouvaient donner leurs expérience se serait super.
Il y a un sujet à ce propos dans le forum anglais: Kinovea capture - which camera do you use?

Go to forum: Français

1,430 Reply by joan

(2 replies, posted in Français)

Bonjour,

Milmou wrote:

Après avoir fait le suivi de trajectoire et le calcul de vitesse, je n'arrive pas a agrandir les indicateurs de vitessse. Il apparaissent en tout petit à l'écran...

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)

Milmou wrote:

De plus après avoir fait un réglage de la vitesse en m/s celle-ci apparait malgré tout à l'écran en px/f...
Comment faire pour modifier cela?

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 ».

Go to forum: Français

1,431 Reply by joan

(2 replies, posted in Français)

Bonjour,
C'est un des soucis qui nécessite des optimisations assez lourdes et une réorganisation de l'architecture.
Le problème est connu, plus le format est long à décoder plus il est critique. (ex: full HD en H.264)

FAQ wrote:

Pourquoi la vitesse de ma vidéo diminue toute seule ?
Cela se produit lorsque Kinovea détecte qu'il ne peut pas extraire les images de la vidéo assez vite pour maintenir la cadence demandée.
La vitesse se stabilise alors à un seuil tolérable mais il est conseillé de la diminuer manuellement à nouveau pour retrouver une lecture fluide.

Go to forum: Français

1,432 Reply by joan

(1 replies, posted in General)

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 sad

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.

Go to forum: General

1,433 Reply by joan

(2 replies, posted in General)

kicker9 wrote:

What I would like to be able to do is have the users who send me their video clips be able to record back to them my analysis not just throu text, but also in speech. Does Kiovea has this application available-or is there a plug-in available for this?

Hi,
Sorry, it is not possible at the moment. And Kinovea does not have a plug-in system.
It will not be added until Kinovea supports audio as input, which is still on hiatus.

Go to forum: General

1,434 Reply by joan

(2 replies, posted in General)

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.)

Go to forum: General

1,435 Reply by joan

(45 replies, posted in Ideas and feature requests)

TeamTermin wrote:

Screen flicker during capture is gone!!!

Great smile
However as noted in the 0.8.11 thread, there is a high chance that the final video created is not properly timed. (It will go too fast relatively to real time).

Go to forum: Ideas and feature requests

1,436 Reply by joan

(1 replies, posted in Ideas and feature requests)

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…

Go to forum: Ideas and feature requests

1,437 Reply by joan

(14 replies, posted in Bug reports)

Hi,
Thanks for the report.
Does it happen with the dual snapshot button (to save an image) ?
Does the crash occur right away or after a few seconds of saving ?
Do you have the overlay function activated (bug 220) ?
Thanks

Go to forum: Bug reports

1,438 Reply by joan

(1 replies, posted in Bug reports)

If I follow, it shouldn't. Maybe it's a bug.

The one important thing to consider is that "what you record is what is displayed". It's not silently recording the live event, it's recording what you see on screen.
You should even be able to change the delay and browse in time during recording, it should be reflected in the video.

Note that due to current implementation, the recorded video has a lot of chance of playing faster than the actual events, especially for large picture sources. (Will be corrected eventually)

Go to forum: Bug reports

1,439 Reply by joan

(6 replies, posted in Français)

Aah, je comprends.
Oui effectivement ce serait bien d'exporter le titre ou le temps absolu des images clés qui sont « traversées » pendant le suivi d'une trajectoire.

lof123 wrote:

L'autre point (disposer les 2 tableaux "Images clés" et "Tracking" à la meme hauteur séparés de 3 ou 4 colonnes) me parait plus important et permettrait d'automatiser plus facilement les calculs.

Je regarderai à l'occasion mais j'ai un peu peur que ce soit compliqué dans l'état actuel des choses, à cause de la technique de transformation du format kva vers les formats bureautique (qui à d'autres avantages par ailleurs).
En gros le fichier de données est parcouru séquentiellement de haut en bas, et le fichier tableur est créé au fur et à mesure, ligne par ligne.

Les deux idées risquent poser le même problème d'ailleurs… hmm

Go to forum: Français

1,440 Reply by joan

(24 replies, posted in General)

Hi,
My feeling is that some of these improvements are fairly independant and should be considered separately for clarity, even if they share the same goal. I'm not against completely re-writing the player screen, a good deep refactoring has been needed for far too long, but if it's possible to tackle these issues incrementally, it's better.
Having a buffer at input for example is not correlated to how the images are displayed.

In this regards, it may be more convenient to split the issues in different threads.
Maybe it's also time to move the discussion to the developpement mailing list… (And sorry Alexander for the thread hijack roll)

So if I wanted to identify independant threads:
1 - Adding an input buffer.
2 - Moving the decoder to its own thread.
3 - Move rendering code from the player control to a new rendering control.
3b - Make rendering controls from different screens use the same rendering surface.
3c - Make rendering control responsible for knowing how to draw specifc meta data objects.
3d - Adding Direct2D rendering control.

3b, 3c and 3d would be dependant on 3, but I think the first 3 could be coded independantly from one another.
I hope I didn't miss anything. What you refer to "drawing data class" is the "Metadata" class I think. It keeps all the things that might be drawn on top of the image.

I have a some more comments, but I think the discussions will start to be hard to track without splitting.
The mailing list page is here if that's fine with you…

Go to forum: General