1,096 Reply by joan

(4 replies, posted in Bug reports)

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.

Go to forum: Bug reports

1,097 Reply by joan

(2 replies, posted in General)

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.

Go to forum: General

1,098 Reply by joan

(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 ?

Go to forum: Bug reports

1,099 Reply by joan

(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.

Go to forum: General

1,100 Reply by joan

(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 ?

Go to forum: Français

1,101 Reply by joan

(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…

Go to forum: Bug reports

1,102 Reply by joan

(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.

Go to forum: General

1,103 Reply by joan

(3 replies, posted in Cameras and hardware)

Could this work with the Network camera interface ? That'd be neat as FireWire is being phased out without proper replacement.

Go to forum: Cameras and hardware

1,104 Reply by joan

(6 replies, posted in Bug reports)

Great! Thanks for the investigation.

Go to forum: Bug reports

1,105 Reply by joan

(10 replies, posted in Ideas and feature requests)

Yes I did ! I'll get back to you soon.

Go to forum: Ideas and feature requests

1,106 Reply by joan

(6 replies, posted in Ideas and feature requests)

@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 smile). Software reconstruction would only be interesting for video got from external sources.

Go to forum: Ideas and feature requests

1,107 Reply by joan

(16 replies, posted in General)

There are many factors smile. 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.

Go to forum: General

1,108 Reply by joan

(16 replies, posted in General)

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.

Go to forum: General

1,109 Reply by joan

(5 replies, posted in Bug reports)

I don't know what the cause could be, hopefully someone with a similar camera can help…
I only have a Sony DCR-HC47 (small Mini DV) that is working fine and with which I do most testing.

Try to get the logs and post them (an exerpt here or the full log in a bug report).
Look for a line like this:
541193 - DEBUG - [Main] - FrameGrabberAForge - Trying to connect to a Capture source.
And see if there are any ERROR lines around.

Go to forum: Bug reports

1,110 Reply by joan

(16 replies, posted in General)

Stuart wrote:

Further info.
I just had a look at my project, it is almost like something is refreshing constantly.  When the video is paused, the controls at the lower right flicker (save picture etc), and on mouse over it takes a while for the tooltip to appear.  Maybe its another Windows 7 thing.

Ha! This.
I think I know where it's coming from. I had made some experiment to make the controls render faster, especially when changing the main window size, to improve the experience when going in or out of full screen mode. (Otherwise you can see each control outline before it's actually rendered, not very nice). After more use, I also noticed that there seems to be a conflict between this modification and the splitter control, especially the one between the list of files and the playback screen. It doesn't happen everytime, but when it does it's horrible.

When this flickering happen (and consumes 100% CPU), try to nudge the splitter left or right to expand or reduce the file explorer panel. In my experience this cause things to fall in place.
I have removed that modification for future versions.

Go to forum: General