1,531 Reply by joan

(6 replies, posted in General)

I'm not sure I see the point of blocking access to a program and at the same time letting everyone know that it is free to get on the Internet ?
Will there be anything else than Kinovea in the restricting container ?

Also, the enclosed instance of Kinovea would have to retain the right to be copied, distributed again, etc. by users — will that still be true ? Will the enclosed Kinovea be independant or just a part of a larger whole ? Can a user get access to Kinovea binaries individually ? If not, they are not independant programs…
I would understand this model for a launcher or an installer, the distributed program being still available individually for anyone to repackage, but I can't see how it could work - technically - for a blocking wrapper.

As the developer, would this be okay with you?

Thanks for asking.
The project strives for maximum openness and availability.
Note that I'm not the only copyright holder, there is more than 15 translators, and of course all the included library with their own licenses.

Also note that you can charge for the program itself, without wrapping it up, this is perfectly allowed by the license.

edit:
I want to state that I like the idea of creating a service-based business around Kinovea. Providing your expertise, knowledge, teaching skills, etc.

Go to forum: General

1,532 Reply by joan

(6 replies, posted in General)

Hi,
I can't really offer legal advice, but here goes:
- Derivative works have to be under the GPLv2.
- A wrapper constitute a derivative work.
From the license: A derivative work is "a work containing the Program or a portion of it, either verbatim or with modifications (…)".

If one could simply create a proprietary wrapper around a GPL software, the whole notion of copyleft would vanish.
From the GPL FAQ: I'd like to incorporate GPL-covered software in my proprietary system. Can I do this?

Maybe you have to better define what you mean by wrapper. If it could be used for any other program, then they are effectively two different programs. Different answer.

Go to forum: General

1,533 Reply by joan

(24 replies, posted in General)

I'm fairly sure it cannot use the direct show codecs. It's not in the philosophy of ffmpeg project and they are just too different beasts.

I think softwares like MPlayer may use an higher abstraction and mix the two to increase formats coverage (microsoft specifc stuff sometimes are not supported in ffmpeg), but it sounds troublesome. (I don't know if it's worth it performance wise…)
There's probably plenty of room for improvement in the rendering stack.

Go to forum: General

1,534 Reply by joan

(24 replies, posted in General)

Phalanger wrote:

Is it acceptable to use third party components like SlimDX (http://slimdx.mdxinfo.com)?  Or would pure Direct2D be better?

Third party components are fine as long as they are open source. SlimDX is under the MIT license so it's perfectly fine.
I was actually considering using this for audio support but haven't had time to really dig into it.

Phalanger wrote:

Also does Kinovea support direct show input? I think it would be better if ffmpeg was simply a full back, as many direct show codes are more powerful (using hardware decoding).

That is more critical since the whole program is sort of built around the ffmpeg time representation coming from the decoder. (I don't know how DX work, maybe there is a common ground)

Also, I'm under the impression that FFMpeg library is pretty well optimised, from my experiments the issue was more with the rendering than with the decoding.
Having better instrumentation of the performance would be a plus to understand where the bottleneck really is. Maybe the bottleneck is not the same for videos with very large image size than for very fast paced ones for example.

And of course FFMpeg already handles almost every input whereas DirectShow will have to rely on installed codecs. If we can mix the two, and use DX where it is know to outperform FFMpeg, why not.
I'd also like to keep the dependencies on Windows specific stuff at a minimum in the event someone is motivated to try a port to Mono…

Go to forum: General

1,535 Reply by joan

(11 replies, posted in Bug reports)

Apparently it would be the 3.5 framework that misbehaved during install and changed the config file innapropriately.

There seem to be others with the same issue, a bug is open at Microsoft but they can't reproduce: Microsoft Connect.

Some other threads about the same issue
http://stackoverflow.com/questions/1292 … sexception
http://community.sharpdevelop.net/forum … 24166.aspx

Apparently the work around is to repair the config file with ServiceModelReg.exe (didn't quite get what was the suggested technique…) or to remove the serviceModel block in the machine.config file, or replace it with a working one. (backup first!)

There doesn't seem to be any way for a program to detect this and repair automatically.
If I understood correctly, this issue prevents any .NET 2.0 application to work.
I'm not even sure that removing the .NET framework and reinstall it would make the problem go away.
sad

Go to forum: Bug reports

1,536 Reply by joan

(5 replies, posted in Bug reports)

That is because VLC (similarly, Kinovea, MPlayer and others tools) do not use codecs at all.

We use the FFMPeg's libavcodec library which itself implement decoding and encoding of the files. The library code is tightly integrated into the software, other softwares cannot use it. There is nothing Kinovea installs that could be used by Windows Media Player, they just work totally differently with regards to decoding files.

The FFDShow codec tries to gather the best of both worlds, it turns the libavcodec library into an installable Windows codec, so with one single piece of software you have the whole FFMPeg suite of decoding/encoding tools available to these codec based players.

Go to forum: Bug reports

1,537 Topic by joan

(1 replies, posted in Français)

Version expérimentale : elle a besoin de vos retour d'expérience pour s'améliorer !

L'installeur est dispo ici : [s]Kinovea.Setup.0.8.11.exe[/s]Voir le sujet sur la version 0.8.12

La principale nouveauté ce mois-ci est le retard sur le direct dans l'écran de capture.

Retard sur le direct
Vous pouvez donc positionner un certain nombre de secondes de retard pour l'affichage du flux vidéo.

À noter que le délai peut être configuré à chaud, cela ne stoppe pas le flux vidéo. Par exemple, il est possible de :
- Visionner une scène en direct, puis augmenter le délai pour la revisionner.
- Pauser la capture, puis jouer avec le curseur de délai pour naviguer dans les évènements récemments capturés.

Le retard maximum qu'il est possible d'atteindre dépend de la configuration mémoire dans les préférences à la page Lecture/Analyse (en attendant une page de configuration dédiée à la capture) et de la taille des images de la source vidéo.

Correctifs : bug 223.
D'autre part le problème de clignotement pendant l'enregistrement sur l'écran de capture devrait être corrigé.
Cependant la fonction d'enregistrement du flux capturé n'est pas encore prête pour du travail sérieux, l'échelle de temps des vidéos créés est fausse la plupart du temps.

Snapshot: capture et délai. Quand la mémoire tampon est remplie à 100%, on peut retarder l'affichage jusqu'au maximum à droite.
http://www.kinovea.org/screencaps/0.8.x/capture.png

Go to forum: Français

1,538 Reply by joan

(4 replies, posted in General)

Thanks for your interest smile
You should be able to switch to spanish already. See menu Options > Language > Español.

Go to forum: General

1,539 Topic by joan

(11 replies, posted in General)

This is an experimental version : it needs your feedback to improve itself.

The installer is available here: [s]Kinovea.0.8.11[/s]Check 0.8.12 thread

Delay on live
The single highlight this month is the delayed live feature in the capture screen.
You can set a number of seconds to delay the display of the live stream.

Note that the delay can be changed at any time, it doesn't disrupt the video flow. For example you could:
- Watch a scene live, then increase the delay by a few seconds to watch it again.
- Pause the capture, then play with the delay to browse the recent events captured.

The ammount of time you can delay depends on the memory configuration in the Preferences at page Play/Analyze (Until the capture has its own settings page) and the image size of the video source.
Please experiment with it and report what you think smile.

Fixed bugs : 223.
Also, there shouldn't be any more flickering when recording during capture.
However, the recording feature is not ready for serious use yet. The time scale of generated video will usually be wrong.

Snapshot: capture and delay. When the buffer is filled 100%, you can delay all the way to the right.
http://www.kinovea.org/screencaps/0.8.x/capture.png

Go to forum: General

1,540 Reply by joan

(6 replies, posted in Français)

lof123 wrote:

1- Il serait donc interessant d'avoir ces 2 tableaux côte à côte séparé d'une ou plusieurs colonnes plutôt que l'un sur l'autre.

Je vais essayer de regarder comment faire.

lof123 wrote:

2- D'autre part, si c'est possible, il serait aussi tres utile d'avoir une colonne supplémentaire à coté du tableau "Track" qui affiche les differentes images clés au temps t de la colonne C. Par exemple s'il y a une image clé à l'image 1000, dans le tableau track, le chiffre 1000 ou un autre marqueur serait inscrit dans une colonne supplémentaire à côté du temps 1000 de la colonne C.

Hmm, pour l'instant tant que c'est possible j'aimerais éviter que l'utilisateur ait à passer par une fenêtre de configuration supplémentaire. Donc il faudrait trouver une solution qui soit acceptable pour tous.
Par exemple: si le format choisi est de type textuel (classique ou classique + numéro images) alors on ajoute une colonne supplémentaire avec le numéro des images, sinon on ne fait rien.

lof123 wrote:

3- Enfin, une derniere question, est-il possible d'afficher la video en plein ecran quand on fait du tracking ?

Pas pour l'instant, mais il doit être possible de zoomer (CTRL+molette de la souris)

Go to forum: Français

1,541 Reply by joan

(11 replies, posted in Bug reports)

I just realised by the look of the log text that you are using version 0.8.7.
The log is actually more complete in the recent experimental versions. It contains the inner exception text, which will be more precise than just "Configuration system failed to initialize" and that will greatly help understand the actual problem.

I should upload version 0.8.11 in a few hours, please try to install it and paste the error text again. Thanks and sorry for the inconvenience!

edit:
0.8.11 is available up here.

Go to forum: Bug reports

1,542 Reply by joan

(24 replies, posted in General)

Phalanger wrote:

Is the display drawn on a direct 2D/3D surface?  I guess this would have great speed benefits and could help with doing slow motion.

No, the image is drawn on a regular GDI+ surface. Indeed, the slowness of this is causing issues with full HD footage sad
I have tried several performance tweaks, including native bitblt, but nothing has been particularly helpful.

I have no experience with Direct 2D though, maybe it could help make the rendering faster…
If you want to try something, the painting is done in /ScreenManager/PlayerScreen/UserInterface/PlayerScreenUserInterface2.cs in method SurfaceScreen_Paint and FlushOnGraphics (there are some comments at the top of this one).

Go to forum: General

1,543 Reply by joan

(1 replies, posted in General)

Hi,
It sounds like a pretty cool project smile
Unfortunately, currently there is not much way to control Kinovea from the outside other than by keyboard/mouse.

Also, this would only be interesting on the live video, and currently the capture screen does not allow to replay the recent history of the live stream at slow motion. (You will be able to browse it manually in 0.8.11 though).

So there is still a long way to go before your project can be implemented, but exposing an interface to the outside world is something that may open many interesting perspectives.

In a related topic, to implement a generic remote control interface, the program will have to expose itself like that to the outside world (on network interface). Maybe the same interface can be used by other programs. In this case, a third party program would simply have to send the right command line on the right socket. That would be nice.

Go to forum: General

1,544 Reply by joan

(3 replies, posted in Bug reports)

Gustav wrote:

I used version 0.8.7 which is the version downloadable from the start page. Are the later versions stable?

Yes, I would consider them relatively stable. Most regressions have been fixed, and the other remaining bugs were either already there in 0.8.7 or are due to new functions.
Once the capture screen is fixed and polished, this should turn into a new official version.

Go to forum: Bug reports

1,545 Reply by joan

(5 replies, posted in Bug reports)

Well, the codecs are not obviously already installed. A freshly sold computer does not come with the DivX/Xvid codec. You have to install it manually at some point.
I'll try and check again what is the minimum stuff to be installed on a virgin Windows to replay the videos.

edit:
So after some tests,

To play back AVI files generated by Kinovea in Windows Media Player on a fresh Windows XP machine:
- For Kinovea versions prior to 0.8.11, you need to install the FFDShow Tryouts codec.
- For Kinovea versions 0.8.11 and later you can either install the XviD codec or the FFDShow Tryouts codec.

The XviD codec is a single codec (small download), the FFDShow Tryouts is based on FFMpeg and will help decode many files. Although it works out of the box, if you need to configure it, the interface is more complex.
Both are open source software.

Go to forum: Bug reports