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
