1,111

(11 replies, posted in General)

Thanks.
Was this with 0.8.15 or 0.8.16 ?
I don't have as many crashes right now, I'll have to investigate later. Yes, the second screen will often be more jittery. However, in 0.8.16 it should not impact recording. (The streaming video may look jittery on screen, but the recorded file is smooth and at the right framerate).

1,112

(11 replies, posted in General)

From my limited experience with capture as a user, 0.8.16 works better for single screen capture, especially with regards to recording, but it has important issues for dual screen capture, even without recording (When I tried yesterday, it was constantly crashing).

I'm not really using this extensively myself so hopefully someone else can confirm.
I'm actually surprised there isn't more comments on these issues if it's been broken in the experimental release (~450 downloads).

1,113

(11 replies, posted in General)

It controls the buffer used in the context of delayed presentation. The higher the value, the more delay can be applied to the live stream.

edit: Dual capture in 0.8.16 and the current version seems very broken sad

1,114

(16 replies, posted in General)

jon wrote:

There seems to be some issue with connecting to network cameras on the capture page. v0.8.16 does not seem to pick up the live MJPEG stream. The stream has been validated to work on v 0.8.15.

I have found and fixed this particular bug. Network cameras should work again in 0.8.17.

Hum… I don't have VS2008 installed at home and never have. I do have the VC# 2008 Express version though. Maybe it comes from there… 
The "Kinovea.Video.FFMpeg.dll" is just the new output name for "PlayerServer" project (C++/CLI, built with VC++ Express 2008). If you don't need to debug it, you may rebuild it in release mode and move forward.

I have a start of an x64 build. Still need to figure out a few things.

1,116

(11 replies, posted in General)

I don't know… In any case there are no temporary files.
Next time you can check the memory consumption, maybe there was a memory leak. (If you can try with 0.8.16 it's better because if the leak is still there I'd like to know). If memory goes up and up, there is a leak. It can take a while until it builds up to get noticed.

Hopefully someone else will come with his/her experience of long capture sessions.

1,117

(11 replies, posted in General)

Thanks for the feedback, it's appreciated.
The issue with the file playing too fast has been addressed in version 0.8.16. Displaying the image and saving it to the file are now in two separate threads. Previously, the saving was done in the same thread, generally the time to process one captured image was longer than the capture interval.

Beware that 0.8.16 also has some regressions apparently (see announcement topic). I hope to get 0.8.17 out in the coming weeks.

1,118

(1 replies, posted in Bug reports)

Hi,
I don't think this camera does live streaming, which is what  the Capture screen is designed for.
The USB port is probably only used to transfer the files from the storage card to the PC.

Typical devices to use with the Capture screen are DV/HDV camcorders (FireWire connection) and webcams (USB connection). (No AVCHD, hard-drive camcorders unless you have a specific capture card for the TV output, DSLR or compact cameras).

Are you on a 64 bit machine ?
I've not tried building on a 64 bit machine yet, so maybe there are some issues. For example C# projects built with "Any CPU" target and the Kinovea.Video.FFMpeg (C++/CLI) one specifically targeting "x86".
Try putting everything to x86 maybe. Not sure what will happen with the system assemblies, will an assembly targetting x86 automatically reference the right versions of its dependencies ?

Alternatively, if you can figure out the dependencies/build process for a full x64 build that would be awesome. We use the FFMpeg builds from Zeranoe, here (version "Dev"). He makes 64 bit builds too.

As you can see in the idea backlog (scroll down to capture category), it is a quite popular request. Currently I'm working on something else, but during the next batch of work on the capture screen it will be evaluated and hopefully implemented.

1,121

(3 replies, posted in Bug reports)

I think I recall someone with a similar error… I'll try to dig it up. What version of QuickTime are you using ?

edit: here, Error -2010 the movie contains some invalid data (test.mp4).
But didn't have enough data at that time to track it down.
Does the .mp4 plays in other players but not in QuickTime ? fails everywhere ?

1,122

(16 replies, posted in General)

HDAV wrote:

Whats the command to exit full screen once in it?

There is no menu to get out yet, use F11 shortcut key.

1,123

(1 replies, posted in Français)

Il faudrait voir les logiciels de surveillance peut-être.

Généralement on fait ça en calculant la différence entre les images successives. On construit une image en niveau de gris, où noir = le pixel est de la même couleur que sur l'image précédente, et blanc = le pixel a changé. (avec toutes les nuances intermédiaires.) Ça marche bien à condition que ce soient des vidéos en caméra fixe.
Ça ne serait pas forcément compliqué à ajouter dans Kinovea. Personellement je n'ai pas trop le temps pour l'instant vu qu'il y a plein d'autres trucs à faire déjà.

Après ça dépend beaucoup de l'application et du cas particulier. Il y a quelques temps je me suis amusé à développer un petit outil pour détecter le déplacement des astéroïdes dans les images d'archive du programme d'observation astronomique NEAT. Dans ce cadre, la meilleure technique est le « blink ». On fait des allers-retours très rapides entre deux ou trois images et on observe en détail pour voir si certains points ont une trajectoire réaliste le long de la séquence ou si c'est juste du bruit.

Quel est le contexte d'utilisation ?

1,124

(2 replies, posted in Bug reports)

This is due to a spam bot posting junk. By the time you went to the site I had deleted the post and deleted the user.
I'm sorry about the spam by the way. I have several automatic routines that prevent a lot of it, but many still slips through… I hadn't thought of this particular annoyance of subscribed topics…

1,125

(1 replies, posted in General)

As of today, I have officially moved the source code to Mercurial and Bitbucket.org.
The new location for the source code is the following:
https://bitbucket.org/kinovea/kinovea/

The various links will be updated soon. The Subversion repository will no longer be updated.