You are not logged in. Please login or register.
Kinovea - Forums → Posts by joan
Hum, I have never tried with .NET 4.0. I hope they didn't introduce breaking changes in the framework.
If anyone else is running .NET 4.0 please report success or failure.
I'll try to set up a machine with it (next week end probably) to try it out.
Which version of Windows are you running, Seven ?
Bien reçu, merci.
Par contre je n'ai pas de soucis pour lire la vidéo dans Kinovea… La durée rapportée est 1 sec 72 centièmes (44 images), est-ce cela correspond ou bien il manque la fin ?
(On ne voit pas la fin du saut, mais c'est pareil dans VLC a priori.)
J'ai d'autres exemples de vidéos au format .m2ts, dont certaines ne fonctionnent pas, mais pas non plus dans VLC…
J'ai oublié de demander, vous utilisez quelle version de Kinovea ?
Hi,
Thank you for the report!
I was able to reproduce the issue and find the problem. I just pushed the correction to the code repository.
(opened and closed bug m187)
Hi,
You can use the File > Save... menu to export the video.
You can export to MKV, MP4 or AVI depending on the saving option.
If you want to retain the drawings / texts, etc. when viewed on another player, you should use the option "Permanently paint key images data on the video".
If you want to retain the drawings / texts, etc. but plan on viewing on Kinovea, you should use the option "Combine video and key images data into the file", this way the drawings stay editable afterwards.
Bonjour,
Dans l'immédiat, la seule solution sera de les convertir en MPG avec le Picture Motion Browser de Sony.
- VLC ? SAIS PAS
Je demande ça car le logiciel VLC utilise sensiblement les mêmes librairies pour décoder les fichiers vidéos que Kinovea. Si cela fonctionne avec VLC cela pointe du doigt un problème dans Kinovea ou une version de librairie plus ancienne.
Si cela ne fonctionne pas dans VLC, il y a moins d'espoir.
Cela serait donc très utile de savoir si les fichiers sont lus correctement par VLC.
Si vous ne pouvez pas l'installer, vous pouvez également m'envoyer un petit exemple (<3MO) de vidéo à l'adresse : joan at kinovea point org.
Bonjour,
Hmm, essayez de faire un clic droit sur le projet "Root" puis "Définir comme projet de démarrage" ou commande équivalente.
Il me semble que lorsqu'on importe une solution il ne sait pas forcément quel est le projet qui sert de point d'entrée. Du coup, il prend le premier qu'il trouve, et ce n'est pas le bon.
Voir également quelques infos correspondantes sur le wiki : building from sources.
Sweet. Thanks for the insight.
Hi,
It is pretty hard for the program to follow a point that changes shape during the video. This is probably what is happening here.
The foot for exemple rotates around the ankle. The hip may be occluded by the arm at some point, etc.
Also, at any given time, there might be some places in the image that actually looks more like the previous position target than the new position of the target itself. This happens when the point to track is small and background get included in the "target". I have experienced that with knee tracking when the person is far from the camera and the leg looks thin on the image.
I would suggest manual tracking at first. Instead of hitting play, just nudge the mouse scroll up a bit to get to the next frame, and see if the automatic tracking is fine for this very frame.
Do this until the tracking goes nuts, and when it does, re-adjust the position manually.
I understand that doing this over the whole video is fastidious 
One other solution (not always an option) is to place some markers on the person.
If you go that route, try to use uniform circular markers. (basically, their appearance shouldn't change when you rotate or translate them.) I found some cheap circular colorful stickers in the kids department of a general store, they look like this.
You can also set dim light conditions and use reflective / led markers.
A sample video may help understand if the issue is that the tracking scenario is too hard to be automatized in the current version, or if there is indeed a defective behavior that should be addressed.
Thanks for the feedback.
Regarding the delayed live, (which I think can be useful in almost any sport to get unattended video feedback), technically, we need to cache frames somewhere to be able to play them later in sequence.
One approach would be to use a global parameter for "Memory Usage" for the whole application.
Such a memory usage setting is currently in use for analysis mode (frames caching) in Player screens, and it could be reused for the capture frame buffer. (meaning setting either a max duration, say 20 or 30 seconds, and setting a max RAM usage, 1GB for instance.)
Asking for RAM usage is not particularly user-friendly, but I couldn't find anything better for playback screens (ideas welcome). That is why it is more or less hidden in the preferences and we try to get good defaults that works for 90% uses. (Currently, 12 seconds and 512MB).
So to sum up, by default you would be able to select a delay between 0 and 12 seconds. For longer delays, you'd have to tweak preferences and increase allowed memory.
(Actually the 12 seconds would depend on the size of images captured…)
Does this sound reasonnable ?
Another completely different approach would be to use an on-disk buffer. In this case the frames would be temporarily stored on the hard drive instead of in memory.
This would allow for virtually unlimited delay (minutes, hours, depending only on hard drive space), but I'm not too sure of the complexity added by this approach in terms of architecture and obviously the loss in performance.
For those interested in the "under the hood" part, here is a schematic of a proposed architecture, using a in-memory buffer. (Comments also welcomed)
Ha ! You only got one wrong, the one I had most doubts about 
The video camera icon (first) was actually intended to be used as a start/pause for frame grabbing. That is, one may use it to freeze the stream sent by the camera on the current image.
I started with a Play/Pause classic icon, but I found it not appropriate for the function…
What you mention (Selecting the capture device) is missing. I thought it would be best if done only once at screen initialization time, but being able to switch device at any point would come in handy. So that means another button.
If anyone think one of these in unclear please chime in !
The "settings widget" was supposed to be a "foldable panel" rather than a drop down menu, the user would fold it by clicking the down arrow on the right (or anywhere in the grey area), leaving only the grey line with a summary of the settings. (unfolding by clicking the grey line again).
I'll upload another mockup.
edit:
So, there are two "camcorder" icons now, but hopefully they are understandable.
Also swaped image and video in the settings panel to match the order of the buttons…
The white area may host the delay slider, and frame cursor when these are implemented.
Let's tackle the user experience part, since it is one of the most important thing, in fact, probably more important than the raw number of features.
I made some UI mock-up, so we can do a little usability experiment 
On the following image representing a tentative capture screen, can you guess what the buttons / icons / etc. mean ?
What do you think they mean ?
Thanks
Hum, in fact this specific interaction is pretty complex and is not clear how / if we will be notified when a device is plugged in.
So, it's probably better to focus on the second interaction: The user changes screen configuration; what do we do depending on the number of camcorders connected?
Then maybe it becomes easier to answer:
Each time there is a new capture screen created, we present the list of camcorders connected that we can link to a screen.
- if we already have another capture screen with a camcorder linked to it we don't list this camcorder as available.
- if there is only one possible device, we automatically link to it and start grabbing its frames.
- if there is no device, we display a small warning dialog.
Does it sound reasonnable for a first shot?
Then we can expand for the connection notification later ?
So, let's say we start with the basic options, 0. frame grabbing, 1. freezing/pausing the frame grabbing, 2. saving the stream to a video file on the fly, 3. displaying the images with a delay, and maybe : 4. browsing directly in the recently captured images without the need to save them to a file.
About saving single frames to disk, a function where you can save the current image with a single click / keypress would probably be interesting too (?)
(with an automatic file name and going to a predefined folder)
Yes, forgot to mention that some thinking is also needed to handle the various cases of camcorders / screens.
This is probably on of the first thing to discuss.
So, basically as a user, we would be able to use the "View" menu to prepare the workspace : select one capture screen, select two capture screens, select a hybrid mode where you have one capture screen and one playback screen.
We need to clear up the user interactivity here because there are many possible scenarios. I'll give them names just in case we need to refer to them later.
Possible screen combinations :
S1 : 0 screen.
S2 : 1 playback screen.
S3 : 2 playback screens.
S4 : 1 capture screen.
S5 : 2 capture screens.
S6 : 1 playback screen + 1 capture screen.
Possible number of devices connected:
C1 : 0 camcorder
C2 : 1 camcorder
C3 : 2 camcorders
C4 : 3 or more camcorders
There are two kind of interactions here:
1 - The user plugs a camcorder to the computer. What do we do depending on the current screens cofiguration + number of camcorders already connected ?
2 - The user changes screen configuration. What do we do depending on the number of camcorders connected ?
Each and every combination will need to be taken into account at some point in the code, so it would be really nice to have a consistent and sensible behavior.
Examples for interaction 1 - The user plugs a camcorder to the computer.
S1 (0 screen) : show a dialog box inviting the user to display a capture screen. If there are already other connected devices, display a list to choose from ?
S2 (1 playback screen) : Should we display a dialog box ? Should we create a capture screen automatically ?
S3 (2 playback screens) : Should we display a dialog box ?
S4 (1 capture screen) : Is it already linked with another connected device ? if not we should directly link the device with this screen. If yes, what do we do ?
S5 (2 capture screen) : Is there an unused screen among the two ? Do we link the device with it automatically ?
etc.
OK, maybe we can group these and just need to define a globally consistent and intuitive behavior for:
- There are not any capture screen available to link the camcorder to.
- There is at least one empty capture screen that we could use.
- There is more than one camcorder that could be linked with a capture screen.
- There is more camcorders connected that we can handle.
Please anyone add your thoughts on what the behavior should be !
Thanks
Yes, being able to cancel long operations is a must !
I need more infos to be able to understand what the issue is.
When the error message appears, you should be able to click on some button to make it display the full error log.
What you are looking for is something that look like this:
************** Exception Text **************
blah, blah, blah.
blah, blah, blah.Please copy and paste this here if possible.
Also, you may try to locate the crash logs of Kinovea as explained in this thread : http://www.kinovea.org/en/forum/viewtopic.php?id=121
If you find some files named "Unhandled Crash", please copy the content here. (or send by mail : joan at kinovea dot org )
Kinovea - Forums → Posts by joan