Search options (Page 94 of 129)

Hi,
Sorry for the delay. Would you be able to send a small sample ?
I'd like to try to reproduce and see what happens internally.
Is it in Full HD image size ? It is possible that the file is too CPU demanding for the current version. When the images can't be decoded + displayed fast enough, the speed slider is automatically slid to the left to try to mitigate the jerkiness.
Thanks

Une méthode est d'utiliser le mode d'affichage « Un écran de capture et un écran de lecture ».
Après l'enregistrement d'une séquence, faire un glisser-déposer de la miniature générée côté écran de capture vers l'écran de lecture. Cela ouvrira la séquence enregistrée avec tous les contrôles de lecture habituels.

Si vous avez une idée précise n'hésitez pas. Si possible en décrivant l'interaction avec le logiciel et le résultat souhaité (je n'ai pas Dartfish sous la main, et de toutes façons faire une copie de fonction serait une mauvaise stratégie, il faut comprendre ce qui est intéressant à proposer, pourquoi, etc. )

Il pourrait être possible d'intégrer des boutons de lecture directement dans l'écran de capture (c'est ce qui était prévu au départ) mais je crois qu'il serait bien d'avoir une idée des cas concret d'utilisation pour pouvoir organiser les fonctionnalités au mieux.

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