You are not logged in. Please login or register.
Kinovea - Forums → Posts by joan
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.
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.
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 ?
Whats the command to exit full screen once in it?
There is no menu to get out yet, use F11 shortcut key.
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 ?
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…
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.
Could this work with the Network camera interface ? That'd be neat as FireWire is being phased out without proper replacement.
Great! Thanks for the investigation.
Yes I did ! I'll get back to you soon.
@edwin, It seems you are referring to two different concepts.
Going from 25 to 50 fps is generally done in the context of deinterlacing. Many videos are actually 50 fields per second, a field being a half image with only the odd or the even lines. There are several ways to rebuild a full image from the two fields. Kinovea use a somewhat basic technique that for this example would yield 25 full frames per second. Some other software may use reconstruction algorithms that gives 50 full frames. This can be advertised as slow motion, but it can only works on video that are interlaced to begin with and only to x2.
The link you gave, is a much much more advanced technology. As far as I know, only two products can do that, both commercial: MotionPerfect from GooderVideo/DynaPel and Re:Vision Twixtor family of plugins (for Premiere, After Effects and the like).
The alternative is to use a camera capable of high speed shooting. For very fast motion you'll want as many frames in the source as possible. As HDAV points, frames reconstructed by algorithms will never be as good as frames actually captured by the device.
For fast motion, if you can control the capture process I would definitely consider a camera capable of shooting at +100fps (Don't need 1 trillion fps 
). Software reconstruction would only be interesting for video got from external sources.
There are many factors . RAM is not really the issue here, it's more the processing power needed to decode and display the images. Lower image size and lower fps will improve things.
The path I have been exploring for the past few months is to have a separate thread that pre-buffers images in parallel to the playback.
The pipeline is now mostly reconstructed, and it does indeed give me better performances and thus less automatic speed decrease. Not as much as I would want, but some improvement nonetheless.
For smooth playback, the real culprit is in the rendering though. And after much experimentation, it's clear (again) that unless the rendering is done in a hardware accelerated technology (either WPF or even the older GDI) instead of GDI+, we will not have a seamless full HD playback for high framerates.
Problem is, WPF means that the whole user interface needs to be rewritten from the ground up. (Some experiments with Direct2D were also made but there was issues to re-convert back images to GDI+ objects for use in the rest of the program…). There is also a WPF control for interop with Winforms, I haven't checked how it could work with existing drawings and other parts yet.
Another route will be to work on a 64bit version and expand the cache size to several gigabytes so it can contain more than the current ~3 seconds of HD footage.
It could be. The speed slider is decreasing by itself when the time to decode and display an image is constantly higher than the time interval between frames. In this case we can't possibly keep up the rate, the automatic decrease is to avoid freezing up the computer.
Kinovea - Forums → Posts by joan