Please try to create a short sample (<3MB) and either attach it to one of these issues in the bug tracker : m165, m184 ; or send it by mail to me : joan at kinovea dot org.

I have been trying a sandbox version with more recent FFMpeg libraries version lately. Some WMV files using the VC-1 codec are fixed by it. Hopefully it's your case too.
(but it changed the way it handles H.264, so we need to do a bit of adaptation work before these libraries can be included to a release.)

Having other samples of these WMV files that don't work will help pinpointing the issue and how to work around it, thanks.

1,607

(3 replies, posted in Bug reports)

Hi,
Currently it is not possible.
It is on the todo-list though. Hopefully coming in a version in a not too distant future.

1,608

(3 replies, posted in Bug reports)

Hum, looking up the error message yields some other cases where this may happen.
Apparently it would be coming from an issue with the .NET installation…

- Problem with Runtime in .Net 2.0:
- unable to find a version of the runtime to run this application

I think you should first list the various versions of the framework that are installed on the machine. It's not obvious that it would be the .NET 4.0 that is causing the issue. Maybe it's one of the previous one.
There is a link to a .NET Framework Verification Tool
Let us know if it detects something wrong.

Then you may uninstall all versions of the Framework and only reinstall the latest one.
If that still fails, try the solution given in the thread on MSDN forums, using the .NET Framework cleanup tool.

1,609

(3 replies, posted in Bug reports)

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 ?

1,610

(9 replies, posted in Français)

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 ?

1,611

(7 replies, posted in General)

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)

1,612

(1 replies, posted in Bug reports)

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.

1,613

(9 replies, posted in Français)

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.

1,616

(1 replies, posted in Bug reports)

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 sad

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 smile

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:
http://www.kinovea.org/screencaps/mockups/capture4.png

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 big_smile

On the following image representing a tentative capture screen, can you guess what the buttons / icons / etc. mean ?
What do you think they mean ?

http://www.kinovea.org/screencaps/mockups/capture2.png

Thanks smile

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)