[Kdenlive-devel] kdenlive

[Christian Berger]

Jason Wood schrieb:
> 
> 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 :-)

OK

> > 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 this is a problem, but all cutting programms have that problem, so
I don't think it's really a problem.
 
> >
> > 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 ;-)

Well the right format is extremely important. I'd go with my last
suggestion. Splitting the cutting into "sceenes" might be the best idea.
The problem is I still have to learn quite a lot of C, I'm not really
fammiliar with it.
 
Servus
  Casandro

> --
> Jason Wood
> I knew I needed a break when I typed <Esc>:q! to close the web browser
> 
> _______________________________________________________________
> 
> Have big pipes? SourceForge.net is looking for download mirrors. We supply
> the hardware. You get the recognition. Email Us: bandwidth at sourceforge.net
> _______________________________________________
> Kdenlive-devel mailing list
> Kdenlive-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kdenlive-devel