[Kdenlive-devel] Storyboard_2 in scene format.

[Jason Wood]

On Friday 22 Nov 2002 12:34 pm, Rolf Dubitzky wrote:
> > Well, partially converted it - StoryBoard_2 is a fairly complicated
> > example with a lot of overlapping transitions, and hence leads to quite a
> > few scenes.
>
> Hmm.. it's just two transitions (shiftin) and on picinpic. Then some
> decoration. I don't think it's very complicated.

It also has two alpha ops and overlayed picture (on top of the pic in pic).

> > As soon as something occurs which changes the tree, a new scene is
> > started. The kinds of things that can cause this are the start or finish
> > of a particular input file, and the start or end of an effect.
>
> Ok. Now I see. Really _every_ time something happens you want to start a
> completely new rendertree. That's why you didn't put any start/length
> information to the inputs/effets. They _always_ start at 0 and always end
> at the end of the scene. I see some problems with this approach:
>
> - Even the simple example leads to quite a few scenes.

I had noticed this when I was trying to convert from your format :-)

> - The idea of keyframes is completely destroyed. To fix it, you either have
>   to do what you did in your example, i.e. split the interpolation at every
>   scene boundary and create new keyframes from the interpolated values.
> This will only work for linear interpolation, or you would also need to
> calculate at least the first derivative of the interpolation function.

Yes, for some reason when I was first considering the idea of scenes, I 
assumed that keyframes would never need to be split - I think I didn't 
consider if two keyframes overlap.

>   Or, you allow for negative keyframes, and repeat all keyframes with
>   every repetition of the effect. Then you have all the information
> available to calculate non-linear interpolations, but the xml-txt is even
> more bloated.

If we are to specify keyframes for each and every scene, it would be better to 
have a "keyframe definition" area in the render list (before the scenes 
start), in which we define the paths, and then reference them in the scenes. 
I didn't like this idea though, as it means that each scene is referring to 
things outside of it's xml tree - breaking it up means doing more work than 
simply seperating out the tree nodes in the XML DOM.

> For the representation in memory I think we agree, that the splitting in
> scenes does not make much sence. I used the easy way and just reproduce the
> memory strukture of a single tree and wrote it to xml. This approach also
> has some problems.
>
> - The xm-txt is hardly readable, even in simple cases, because even if you
>   just add a few clips, without any effects, you'll end up with a deep
> tree. In this case it would be much more intuitive to have a sequences of
> scenes as you suggest.
>

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

> What about a mixed approach? I my experience (which is of course very
> limited and biased), I usually want to edit my video from vacation or make
> some funny clips of parties and events where I have been. Usually, I have
> at least a complex intro and a complex credits part at the end. In the
> middle I have parts where you just see whatever was on the tape,no editing
> at all, then from time to time I have a transition with s few effects or
> overlay some soundeffect etc.

My experience comes from the student television station I was involved in (and 
still am involved in even though I have now graduated ;-))

Usually our edited shows take a similar form - you have heavily edited intro, 
credits and cut scenes in the middle. The intro, it could easily contain over 
a hundred clips in a minutes worth of footage, with a huge number of 
transitions.

>  So if we really need to split the whole production into scenes, then why
> not split it in scenes of high complexity and low complexity.

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

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.

>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? So if I pass you lots of scenes, then 
except for it being supoptimal from your perspective, it will still work. 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.

And then we can figure out the best way to split scenes up more sensibly.

I think we can discuss this more, but it will be a while before it affects us 
- without transititions, scenes are essentially limited to :

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

So we can continue coding towards our high priority goals whilst discussing it 
:-)

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