Search options (Page 103 of 136)

I've started to read about Direct2D and I must say it's pretty exiting.
Moving the rendering to the graphic card will not only increase performance through hardware acceleration, it will also free the CPU for other computations.
Stuff like tracking multiple points might be able to run in real time, that would be awesome.

The drawback is portability to other OS (although I've seen something about X support…) and to older Windows versions. (Which might mean having to maintain/release two versions, but this will be a good excuse to finally try some of the new features of .NET 3.5, like the graphic tablet API).

Anyway, yes, it would be good to use this opportunity to refactor the player screen and decoding/rendering flow.
I have added a diagram of the current architecture here to help.

I like the idea of bufferring the incoming images. It won't be necessary when images are already extracted to memory though, but when decoding directly from file, it will help smoothing out the decoding time.

On the other side of the flow, when outputting to screen, the ideal way is like you say independant modules that take the image and data and draw them on their surface, be it GDI+, Direct2D or whatever.
(An "output modules" architecture would make more sense when we want to add back support for document rendering, we would just have to implement a PDF or ODF renderer.)

Passing the list of items to the renderer would completely change the approach for drawing though… As of now, each drawing has a Draw method, and is responsible for drawing itself on the GDI+ surface according to its own internal data. It's convenient and good encapsulation.

Abstracting the output would mean completely redesign this aspect. This needs to be thought carefully.
For instance, the exact same flow is used when saving snapshot or video. We just pass a new Bitmap to draw on instead of the control's Graphic.

One other way would be if renderers could be abstracted and the concrete selected renderer passed to the Draw method of each object.
The object would draw themselves using universal primitives, and these would be translated to actual methods in the concrete renderer.

What do you think ?

Hi,

First of all, I will use this opportunity to say that the idea initially discussed at the top of this thread has been implemented in the latest experimental versions.

So when you have a 210fps video configured, the speed slider will actually not go from 0 to 200%, but from 0 to 28.5% (if the video file is crafted as 30fps).
And the speed percentage will refer to the percentage of speed relatively to the actual action.

So your issue becomes "how do I get back to 100%?".

Unfortunately, it's not simple. It was also asked a while back on the french part of the forum, and the issue I found then is that all the frames creating the slow motion are to be decoded anyway. We can't just skip 9 frames out of 10 to go 10 times faster. We have to decode everything (to reconstruct a given image, information from the previous ones is needed).

In this case this means decoding 210 images per seconds, even if we only render some of them to recreate the illusion of normal speed.
It will be extremely hard to keep the pace. For videos shot at 300, 600, 1200 fps or more, it will just be impossible.

Currently I don't see a real time solution to this. The only thing we could do is your point 2, create a new video and decimate frames on the way.
In this case we could recreate the original motion. It would be like creating a timelapse video of a slow motion

Ok, peut-on approfondir ce point ? J'avoue ne pas voir précisément ce qu'apporterai une colonne supplémentaire.

En basculant l'affichage des temps vers « numéro des images » ou « total en millisecondes » la colonne C actuelle sera remplie par des valeurs numérique. Imaginons une colonne supplémentaire, on y mettrai quel type d'information ? C'est pour avoir à la fois le temps sous forme classique et le temps sous forme numérique ?
Merci

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.

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.

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…

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.

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