Re: [Kdenlive-devel] kdenlive

[Jason W. <jas...@bl...>]

On Friday 03 May 2002 9:39 pm, Christian Berger wrote:
> I'm sorry for not replying in full last time

Don't worry - I have had zero time in the last 24 hours to reply anyway. 
Actually, this is the first evening this week where I've actually been able 
to sit down and look at kdenlive's code :-)

> Jason Wood schrieb:
> > > Well It doesn't make much sense, no 2 effects can access the same video
> > > simultainiously. I would prohibit that. But if you close the files, you
> > > cannot access them anyhow without difficult seeking and maybe even
> > > decompression or something. So we shouldn't do that.
> >
> > It might make sense is, for example, if you wanted an effect which placed
> > the same video on screen simultaneously multiple times at different
> > locations (perhaps behaving like a particle effect). You would either
> > have to a) open the same file multiple times, which may be your only
> > option if the video that you want to display will be open a different
> > positions, or a more effective way would be to have the ability to have a
> > single file piped to multiple effects (each of which would perform a
> > seperate translate/rotate/scale transform on the video).
> >
> > However, in this case, you would have a seperate special effect which
> > would take a single input, and send it to several outputs - it would
> > handle any problems that might occur if other effects tried to pull
> > different numbers of frames from it.
>
> Well I would do it like this: I have several input modules, and several
> effects can access the input modules at once. All effects are calculated
> and all the inputs advance a bit (to the next frame for example)

The main difficulty that needs to be considered is if there is an effect which 
needs multiple frames at once - something like Nemo tv in effectv did (if I 
understand the way it worked correctly at least). If one effect needs to 
pull, say, 20 frames from the input before it can output it's first frame, 
then we have to make sure that we buffer everything correctly so that if 
another effect only requires one frame from the same input that we do not 
have to keep seeking around the input file to keep both effects satisfied.

>
> Well I have a new idea this is an example for functional programming  :)
>
> openfile -name "input1" -filename "Input1.avi"
> openfile -name "input2" -filename "Input2.mpg"
> outputfile -name "output1" -filename "output.mp4"
>
> scene -name "Some name just for comments" -duration
> play #1
> #1 pip -input1 #2 -input2  "input1"
> #2 fade -start 20 -stopp 80 -input1 "input2" -input2 #3
> #3 mosaik -input "input1" -raster 5
> sceneend
>
> So we actually have some "functional attempt" at the "language". Ohh my,
> I've gotta learn a lot of C++ in order to be able to program this :)

To be honest, the last several formats that we've been throwing around now are 
basically the same idea, with different amounts of syntactical sugar thrown 
on top. I'd pick the one that looks easiest to parse, so that you can 
concentrate on the main task of actually cutting files together, rather than 
trying to figure out what your supposed to be cutting ;-)

-- 
Jason Wood
I knew I needed a break when I typed <Esc>:q! to close the web browser