[Kdenlive-devel] Operators and Properties

[Rolf Dubitzky]

Hi Jason,

from this discussion I guess we are pretty much on the same track ;-) Very 
promissing ;-)

On Monday 04 November 2002 08:27 pm, Jason Wood wrote:
> Neither am I, scenes are what I used within the cutting list specification.
> I used a screengrab of the timeline as a simply means of showing (I hope)
> how I would break down the graphical representation to create scenes.

Ok, good. And why again do we need scenes?

> Ok, here is the way that I see it as working at present :
>
> 1. The Timeline is represented as shown, with tracks capable of sliding
> over each other, they can be resized, chopped up, have effects, applied,
> you name it.

Ok.

> 2. When we want to render something (preview, production, etc.) We take
> this internal GUI representation and translate it into a number of scenes,
> which we then pass onto a scheduler.

Why break it up in scenes?

> 3. The scheduler looks at the scenes that it has been asked to process,
> compares them to scenes that have already been processed, and substitutes
> in any pre-rendered caches that it has for scenes, or partial scene trees.
> The now-modified scenes get passed onto the the renderer(s) to be
> renderered.

Except for the scene-part. Great.

> (On a sidenote, it's hard to describe how the scheduler will work, but it
> effectively acts as a proxy between the GUI and the cutter(s), and is their
> to make the most effective usage of resources that it can. Essentially, it
> should be transparent to both GUI and the cutter.)

Well, If you eant to render a 60 sec part on ten mashines, why not split it up 
in ten 6 sec parts? A further improvement can be an analysis on predicted 
render speed based on the complexity of the tree and then pass chunks of 
equal predicted rendertime to the ten renderes. I mean, if the whole 
production is represented as a single tree, you just pass this tree to all 
renderes and tell them which frames (time intervall) to render. Why break it 
up in scenes?

> Just in case I am not clear about what a scene is, a scene itself is
> represented as a tree in the same way that you represent media elements,
> (operators, nodes, leaves, the lot) but they are strung together in serial
> fashion to make the entire movie.

Ok, good, that's what I understood, but good to be sure.

> If you like, a scene is a "building block" element for a movie. It
> describes a transition between two videos, or an effect of a part of a
> video, or just the playback of a single video, or it could describe how 30
> seperate videos should be combined correctly to perform a complex effect.
> But it only describes one such thing, and then another scene takes care of
> the next bit of the movie.
>
> As far as I can tell, this "should we break the tree up into chunks or not"
> is the only difference between your view of how the cutting list should
> work, and my view.

Yes I agree, and that is really not a big difference. I guess this difference 
will be washed out as the project matures, we'll just see what we really 
need. Maybe I just can't see far enough at the momen.

> Effectively, it is your idea of a PropertyNode. You specify "key frames",
> which are those frames where you specifically say "This property should be
> this value at this time", and you specify what interpolation needs to occur
> to get from one key frame to the next.

Yes, that is what I mean.

> I really don't think this is worth arguing over at this moment in time.
> Let's discuss again when we are implementing the interface for transitions.

Agreed ;-) As I said, we'll see more clearly what we need as we code on.

Cheers,
Rolf

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