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

[Jason Wood]

(note that this email was written under the infuence of alcohol)

On Wednesday 23 Oct 2002 1:48 pm, Rolf Dubitzky wrote:
> > 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.

Ok, you can't have a 100% seperation, but the important part of the interface 
- playing, recording, timeline, project management, etc. can be seperated. 
Essentially, the engine needs only to be able to display video itself, which 
is a hack for speed reasons over the "perfect" solution (of chucking the data 
to the GUI for it to display)

I am not convinced that we cannot create a communication layer that is 
implementation independant - I see the need for the GUI to recognise the 
limitations of the engine, but that, I believe, can be handled by a suitably 
comprehensive "ok, tell me what you can do" type of command, that returns a 
list of everything that the engine is capable of.

At the least, the majority of functionality (available frame rates, video 
formats, transitions, effects, export formats) can be included in the 
interface which will be much better than nothing.

If I look at the engine recognising the limitations of the GUI - that's not 
essential. If the engine is capable of something that the GUI can't do, the 
GUI will simply never ask the engine to do it.

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

I am not so sure that it is not possible to come up with a generic GUI. 
Christian and I put together a specification on how to transfer data from the 
GUI part of the program to the engine, which essentially works as a 
tree-based view. This is not how my GUI works however; it needs to translate 
the data to this view model.

In the same way, I am wondering how much translation would be required to 
reach your view model?

If you want to look at the last cutting list specification we wrote - i.e the 
data we should send to the engine to tell it what we want to achieve - then 
you can find it on this page :

http://www.uchian.pwp.blueyonder.co.uk/kdenlive_documentation.html

We have been discussing converting the overall format to XML  to make it 
easier to parse (by using a generic XML parser such as libxml).

As an example though, here is a sample (as XML) as to how a particular effect 
might be described :

<scene name="some scene" length="30">
        <fade start="100" end="0">
                <colorgen color="#000000"/>
                <overlay type="screen">
                        <text color="#FFFFFF" x="centered" y="bottom">
                                A Kdenlive Production MMII
                        </text>
                        <file filename="test.mpeg" start="0" speed="1"/>
                </overlay>
        </fade>
</scene>

This would describe a piece of output video (which would be one of many laid 
out serially), that is overlaying the text "A Kdenlive production MMII" over 
"test.mpeg", which is being faded to black (colorgen color "#000000").

How easy would it be to add a translation layer that could turn this into 
something usable by your engine?

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

Better to ask Christian on the state of his engine, we often discuss the 
interface between how the GUI and engine/cutter should interact, but on a 
coding level, we have so far worked completely independantly.

>From my point of view, I would love to create a generic linux video editing 
framework that is independant of GUI and Engine. So if your friend is 
interested in, say, a Gnome, or pure GTK GUI, then that is totally fine by me 
:-) The important thing is interoperability between various cutters/engines 
and GUI's.

Cheers,
Jason

-- 
Jason Wood
Homepage : www.uchian.pwp.blueyonder.co.uk