acer22 wrote:

I am seeing the same issue with version 0.8.18 as well.  I am finding that the lag on arrowing backwards can be quite bad. I will push the back arrow several times and not see any advancement and then all of a sudden I will get several frames.

Hmm, I don't think they are the same problem. The issue mgerner has is that each frame of the captured video has been duplicated in the capture process. So when you go step by step, the actual image only changes one time out of two. It's independant of other issues. I don't know if it's coming from Kinovea or if the frames come like this.

What you describe sounds like the classic issue of stepping backward in videos using interframe coding. A seek is needed which can be quite costly (we jump to a keyframe, then decode everything until the target). The preroll cache should mitigate this issue. Could you test with 0.8.16 and see if it's better/worse. Please start a new topic with your findings to keep this one about network capture.

@mgerner: try to put all the settings to the minimum values to see if it's related to processing time or not. Can you try to record the same camera in another application ? That would also help understand if the issue is in Kinovea or elsewhere in the chain. Webcam XP (free) should be able to capture it.

992

(4 replies, posted in Bug reports)

I won't be of much help except to say that it does work on my Win7 64bit machine at work.
The error in this context seems to be pointing to a missing .dll somewhere in the .NET Framework. Maybe try to uninstall and reinstall .NET, manually or through Windows update if possible. (You can install 3.5 instead of 2.0, but one of these two must be installed).

Still interested by the log from the verification tool. Please attach it to bug 288.

Thanks for the sample, I reproduce the issue you describe, it's probably a problem during the recording process, not during playback.
Does the camera have several configurations ? If so could you test with various image size/framerate and see if the issue is consistent or if it only happens for higher values ?

Another longer term idea, input welcome big_smile

Today the range of values for the speed slider is mapped like this:

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


With a logarithmic scale, it could be like this:

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

Advantages
- more precise in the slow motion area of the mapping, where it's most important.
- can go up to high values without eating too much space.

Drawbacks
- less natural changes when manipulating the slider ? (there are no tick marks on the actual control, only the current value is displayed).
- too much space eaten by very low values ?

Going up to 10x (or more) would be interesting for two features: 1. playing a high speed video back to normal speed, 2. playing a long video ultra fast to quickly scan for interesting sections. Technically, to keep the pace, instead of trying to play every frame, we would jump and skip as many frames as needed.

I'm not sure about the final displayed value though. I think for slomo "10%" is better than "0.1x", but for high values, "10x" makes more sense than "1000%". Mixing the two is not entirely satisfying for some reason.

A more advanced mapping function could be experimented with maybe.

This is an idea at incubation stage for longer term perspective, input welcome big_smile

The concept would be to be able to attach playback commands to key images. For example, you would attach a "Pause for 3 seconds" command to a particular key image. During playback, the video would pause 3 seconds and then resume.

Here are some ideas for these actions or commands (better name welcome):
- Pause playback for a given duration then resume.
- Pause playback and reveal drawings one by one like that effect in PowerPoint. (Hmmm, actually hard to do since there is no visible notion of order in the drawings…).
- Switch to a different slow motion value until next key image.
- Jump to next key image. This would allow to define non-interesting zones and skip them during playback.
- Jump to previous key image. Loop like this for a given number of time, then resume forward.
- Jump to an arbitrary key image or time position.
- (future) If we have animated drawings, pause playback, animate the drawing, resume playback.
- (future) If we have audio comments, pause playback, play audio, resume playback.

Can you think of any other? What would you use it for?
Some of these might be honorable during saving video, which would be neat.

You have this only on files recorded from capture screen or on all files?
Do you have the Image > Deinterlace option on by any chance?

It's like it would record the same frame twice and discard the new one… I'll have to try to reproduce the problem.

Hello,
You should try the experimental version 0.8.18 to see if the problem remains. There were changes to the capture recording process and changes to the playback pipeline that should improve performances.

998

(22 replies, posted in General)

wermouth wrote:

In regards to playback speed, I was talking about Kinovea version where you could set the speed of video playback separately in two playback screen mode, then you could play let say in one screen 80% and other 100% and you had third button on the bottom of the program to Vary playback speed for both screens at the same time.

Yes. I think this change was because when playing two videos to compare them, one would prefer that the speeds of actions change in sync, otherwise you can't really compare the actions.

Playing two videos at different speed is a strange scenario… unless one of the video in already in slow motion and not the other, but for that specific scenario the sliders use the adjusted speed, so both actions run at the same percentage of "real world" speed, even if one video is in slow motion to begin with. (Also, difference of framerate in the videos is already accounted for).

If you have a different scenario where you want to play the videos at different speed, or if it's one of the scenario I mentionned but it doesn't work as expected, I'd like to understand more smile

For the next version I did add a checkbox in the settings, to disable the synching of the speed sliders globally.
However, as you say, it was certainly more convenient when you could alternate between the two behaviors directly in the interface. Maybe the checkbox could be in the common controls bar instead. But for now I still think it's not a very common scenario.

999

(22 replies, posted in General)

Yes, spotlight is trackable in the next version (as well as angles, lines, markers, the magnifier, and also the new custom tools).
(I'm currently looking for small bug fixes or mini features to pack in).

There is one piece of architecture that was introduced in version 0.8.17 that would make this much easier to implement than before.

I think what is needed to go forward on this topic is to settle on a data format. Converting the raw data into graphics shouldn't be too difficult.
What is the most common data format for timed values ? Plain old CSV ?

1,001

(22 replies, posted in General)

wermouth wrote:

Unfortunately video synchronize video doesn't work well sad

Could you elaborate on what doesn't work well ?

wermouth wrote:

I would love to see what was in v15 or 14 that you can play two videos with different speed

Are you comparing a high speed camera video with a normal one or is it another scenario ?

1,002

(7 replies, posted in Français)

Hmm, hm!

D'après ce que je comprends il y a un périphérique de capture appelé Asus GSB d'installé sur la machine. Apparemment c'est un périphérique virtuel de capture d'écran qui est installé automatiquement avec les cartes graphiques Asus…
Comme il apparaît en premier, par défaut, Kinovea essaie de se connecter dessus. Et là ça plante pour une raison que j'ignore.

En cherchant plus d'infos je suis tombé sur des messages de gens qui avaient le même problème avec ce pilote Asus GSB sur d'autres logiciels de capture vidéo. Par exemple ici avec Skype.

Un contournement suggéré dans ce lien est d'aller dans le gestionnaire de périphériques, sous Contrôleurs audio, vidéo et jeu, et désactiver le périphérique virtuel Asus.
À voir si ça marche… En attendant de comprendre plus précisément le problème.

1,003

(7 replies, posted in Français)

Bonjour,

Quel est le message d'erreur ?
Si c'est avec la version 0.8.18 je serais intéressé par récupérer les logs pour analyser le problème. (Après le plantage et avant redémarrage de Kinovea, aller dans "C:\Users\<nom d'utilisateur>\AppData\Roaming\Kinovea" et copier les fichiers log.txt et autres Unhandled Crash.txt).

Quel est le modèle de camescope/webcam ? La même caméra fonctionne sur le portable et pas sur le fixe ?

Il y a un bug ouvert - 272 - qui correspond au problème, mais je ne le reproduis pas. Les logs seraient donc d'une grande aide pour le diagnostic (les attacher directement au bug si possible).

1,004

(3 replies, posted in Bug reports)

The issue was that the drawings were drawn in the "display" coordinate system even when recording or taking a snapshot. But when recording we always use original size, so when original and display sizes differed, the drawings were misplaced.

It'll be fixed in the next version.

1,005

(3 replies, posted in Bug reports)

It's probably a bug, I'll try to reproduce it. Is the camera resolution higher than what fits in the screen ?