[Kdenlive-devel] Storyboard_2 in scene format.

[Rolf Dubitzky]

Hi,

On Thursday 21 November 2002 04:39 pm, Jason Wood wrote:
> I have now looked at createStoryBoard_2() from Paive, and have converted
> into the format that I would expect it to look in the current StoryBoard
> format in the Spec.

I had a look at your implementation and I catually also managedto find some 
time to update piave to the latest libxml++. I'll commit to CVS asap. 

If you run "piave -o test.xml"  you can produce xml from storyboard2 (I also 
attached it to the end, so you don't need to do it). As I said, I am not 
suggesting to use this format, it was invented for a completely different 
purpose. I wanted to see what I construct in memory, including all the 
NullOps and other stuff nobody would care about outside libpiave.

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

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

- You can see from your own example, that this approach leads to an enourmous 
  duplication of xml-txt. you have to repeat all inputs for every scene they 
  appear in. You have to repeat all effects with their parameters for every 
  scene. Usually you'll have at least a deinterlace and a denoise filter on 
  top of each input file. You'll have to repeat those every scene, too.

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

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)


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

Example 1: 
  --------------input1----------------
                         ===effect1=== 
                         ------------------input2-------------        
                         ^           ^
     split here:         |           |

That is identical to your suggestion. Only remaining disadvantage of the 
splitting, is that you have to repeat the input files a few times (actually 
only once).



Example 2:
                                ======text==========
  ------in0------ ---------in1--------------- --------------input4-----
                                ==pip== ==shift=====
                                --in2---  ---still--
                                ==fad====== ==eff4==
                                -----in3------------
                  ^             ^                   ^
  split here      |        here |          and here |


This example is very common I think. You just cut scenes together, but when 
you reach the next city of your trip, or te next birthday od the baby, or 
whatever, you want to blend over, add a title for the new chapter, and show a 
X in the map of the country where you have been, or whetever. It should be 
rather easy to identify complex and incomplex parts, just count the layers 
and/or the complexity of the effect/interpolation.

This would lead to exactly what you suggested with scenes in the case of a 
simple movie where you just concatenate clips w/ or w/o transition effects 
between them. In the extreme case of a very complex MTV video clip, with 25 
effects per frame and 34 gazillion inputs in 3 minutes it would lead to a 
single tree. 

I think, this way we can catch the advantages of both approaches, as we can 
handle simple (sub)projects in a simple way (sequence of scenes) and complex 
(sub)projects in a way that allows maximum flexibility (tree).

What do you think? Can we discuss this?

Cheers,
Rolf


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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.xml
Type: text/xml
Size: 3204 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20021122/cd3f9ca6/attachment.xml>