[Kdenlive-devel] moved here from kde-multimedia (was Re: Multimedia Frameworks)

[Rolf Dubitzky]

Hi Jason, hi Christian,

> On Wednesday 23 Oct 2002 10:14 am, Peter.Q at gmx.net wrote in thread:
>    http://lists.kde.org/?l=kde-multimedia&m=103537308631406&w=2
>
> Essentially my idea has always been based upon the GUI and engine running in 
> seperate processes and communicating between each other. BUT before 
> everyone starts wailing and nashing teeth at how slow chucking
> video from one process to another would be; the plan I have is that the
> engine will display it's own video window, which will then be embedded into
> the GUI. So no video will be passed from GUI to engine.

Ok, that is a must. You cannot pass any video data arround.

> timeline and moving them around at least one at a time, and in some cases
> multiple selections at a time (the code just needs finishing off to make it
> work in all cases). As I mentioned above though, I was thinking that for 
seperation it makes
> better sense to put the KVideoWidget into a simple window in the engine,

Well, I think this is one of the points I meant, when I said that you will not 
be able to separate engine and GUI 100%. Putting a KVideoWidget into the 
engine is clearly not what I want. But that is not a real problem. Any two 
parts need a inteface layer. This layer will necessaryly depend on a specific 
GUI and on a specific render engine. I think that such a layer will not ruin 
a nice design. And btw you will need at leas two video windows. Ony in which 
you see the curent frame, maybe rendered in preview quality, maybe even with 
low quality, but HW accelerated versions of the effects, and another kind of 
window to preview subscenes that have already been rendered. My engine will 
be capable (not yet working) of using idle time to prerender parts of the 
production so that they can be quickly displayed.

> and to then control it remotely. The most difficult bit of this will be 
> actually settling on the actual format of the communication.

This communication will very much depend on the capabilities of the engine. 
E.g. I don't use a serial timeline. It's more like a tree. This is extremely 
efficient and easy to manage, but not vary convenient to visualize. Same is 
true for effects and transitions, actuall, in my engine there is not even a 
difference between the two. I use dynamic path effects, which can appear like 
transitions, or something else. It's a very nice concept I think. I just 
mention it to make clear, that the path nodes have to be visualized in the 
timeline which means, that it will be difficult to write a generic gui and a 
generic engine with a generic interface.
 On the other hand, you are right, there are a number of things basically 
every engine and every gui will have in common, but you probably don't want 
to restrict yourself to this common denominator.

And then, may I ask about Christian Berger's engine? In which state is it? Are 
you two working closely together? I work together with a friend of mine who 
is doing the GUI stuff, I would like to try and convince him that we all work 
together, but I am not sure that'll work. He is not eager to work with Qt.

Cheers

P.S. Don't be puzzled about the e-mail. 'Peter' is a nick and an old alias, I 
use when mailing from home.

***************************************************************
 Rolf Dubitzky  
 e-mail: Rolf.Dubitzky at Physik.TU-Dresden.de
 s-mail see http://hep.phy.tu-dresden.de/~dubitzky/
***************************************************************