[Kdenlive-devel] Storyboard_2 in scene format.

Rolf Dubitzky dubitzky at pktw06.phy.tu-dresden.de
Fri Nov 22 15:50:23 UTC 2002


On Friday 22 November 2002 03:20 pm, Jason Wood wrote:
> On Friday 22 Nov 2002 12:34 pm, Rolf Dubitzky wrote:
> > - The tree is not easy to split in seperate parts if you want to send it
> > to multiple renderer instances. (You could of course always send the
> > complete tree to all instances and tell them to render different parts)
>
> More than just splitting the tree for distributed rendering, but it is also
> difficult to work out which parts of the tree have already been rendered.

No, that's not true. You can just take the whole tree, and renderer 1 is 
rendering frame 0-1000, renderer 2 frame 1001-2000. It's _very_ easy.

> I agree in principle, but I think this is going to be a difficult heuristic
> to figure out.

Well, I am not sure. 

> I think the best way to proceed it this : we relax the restriction on
> scenes that effects and inputs must traverse the entire scene. But we leave
> it up to the GUI as to exactly how it implements these scenes. By this, I
> mean that a scene could be the strict definition I propose, or it could be
> an entire structure like storyboard_2.

Yes, I definitely gree, that the GUI is responsible to split the whole thing 
ino scenes whereever it feels to. I just think the whole comunication will be 
much easier to code if we don't split dynamic effects to pieces.

> From your perspective, none of this matters - from what I understand of
> your rendering structure, you can easily put scenes of any complexity next
> to each other to form the full render, right?

Correct, I just worry about the communicational overhed beeing very high and 
also beeing a showstopper for new features. In the tree aproach you can do 
fancy effects very easy, if you _have_to_ split it to atomic pieces, things 
will get complicatet.

> So if I pass you lots of
> scenes, then except for it being supoptimal from your perspective, it will
> still work.

Sure.

> If I passed everything as one scene, then it would be
> suboptimal for the GUI and calculating what has been rendered previously,
> but it would still work.

No, I disagree ;-) That's why I bother to discuss this at all. From the 
renderer's perspective it won't matter anyway as you say. I just think from 
the GUI point of view you'll gain a lot of simplicity if you don't have to 
split (at least complex sequences) into seperate selfcontaining scenes.
Maybe it's my lack of coding for the GUI, but what makes sequences with 
overlapping elements more optimal than a tree for the GUI?

> So we can continue coding towards our high priority goals whilst discussing
> it

Great ;-) Agreed ;-) 

So let's make the following milestone 2.

<scene duration="20.0">
        <input file="avchunk1" inpoint="0.0" outpoint="20.0"/>
</scene>
<scene duration="20.0">
        <input file="avchunk2" inpoint="5.0" outpoint="25.0"/>
</scene>


where milestone 1 would then be <createWin  ... > <play...> <quit>

What do you think?

Cheers,
Rolf

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






More information about the Kdenlive mailing list