[Kdenlive-devel] kdenlive

Thu May 2 15:41:20 UTC 2002

Jason Wood schrieb:
> 
> On Wednesday 01 May 2002 8:18 pm, Christian Berger wrote:
> > Jason Wood schrieb:
> > > On Wednesday 01 May 2002 09:51, Christian Berger wrote:
> > > >
> > > > Well for preview I would use a lower framerate as well as render all
> > > > the effects in a low resoultion. But I don't think we'll be able to
> > > > reuse that data. At least I wouldn't really put much energy on that.
> > >
> > > It may well depend on which cutter program and the user's hardware though
> > > - if we can generate full quality output quickly, then we might as well
> > > make the preview images full quality, in which case they can be reused.
> > > The only advantage (though a major one) of low quality preview files is
> > > that they can be rendered much quicker than high quality preview files.
> >
> > Well I guess one problem is, our "preview" won't be much faster than the
> > real thing. There is also the same problem with other programms,
> > rendering a preview can take longer than doing the "real thing" under
> > many cirumstances. However, well let's see.
> 
> Agreed
> 
> > > Sorry, I haven't made myself clear here - filehandles is not the best
> > > term for what is supposed to be happening. What we have is more a
> > > description of the "paths" that videos have to traverse through effects
> > > in order to make this particular video.
> > >
> > > Take a look at the image attatched. Here, I have shown how one particular
> > > piece of the output video may have to be constructed. It consists of 5
> > > files and 7 effects, some of which require previous effects to have been
> > > computed first, and some which require multiple effects to have been
> > > calculated.
> > >
> > > The identifiers for "inputs" into effects and "outputs" from files and
> > > effects are really just that - identifiers showing how to get from one
> > > effect from the next - in other words, each line gets a seperate
> > > identifier. By reasoning that they should be "closed" after use is to
> > > guarantee that a line only has one input and one output - a useful
> > > simplification as it prevents two effects from trying to access the same
> > > video and messing up when it seeks forwards after each.
> >
> > 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.
> 
> > for effects with 2 videos we always have to have one "master" video and
> > a slave one, because we have different framerates.
> >
> > So we would have something like this:
> >
> > open file1 a
> > open file2 b
> > pipe p1
> > play -in a -out p1 -effect "effect1" -effectparm b -effect "effect2"
> > -effectparm 34
> > close a
> > close b
> >
> > open file3 a
> > open file4 b
> > pipe p2
> > play -in a -out p2 -effect "effect3" -effectparm b -effect "effect4"
> > -effectparm 34
> > close a
> > close b
> >
> > pipe p3
> > play -in p1 -out p3 -effect "effect5" -effectparm p2
> > close p1
> > close p2
> >
> > output result.avi x
> >
> > open file5 a
> > play -in a -out x -effect "effect6" -effectparm 34 -effect "effect7"
> > -effectparm p3
> > close a
> > close p3
> >
> > Pipes aren't designed for multithreadthin, but to temporarily store
> > data.
> > A line like :
> > play -in a -out x -effect "effect1" -effectparm a
> > should not be allowed and be rejected by the parser.
> >
> > >
> > > In my file definition, this would be simply defined as follows :
> > >
> > > # First greenscreen clip + background (colorised)
> > > IN 1 file1.avi
> > > IN 2 file 2.avi
> > > EFFECT 3 chroma 1 2 (options go here)
> > > EFFECT 4 colorise 3 (options go here)
> > >
> > > # Second greenscreen clip + background (in hell, flame effect)
> > > IN 5 file 3.avi
> > > IN 6 file 4.avi
> > > EFFECT 7 chroma 5 6 (options go here)
> > > EFFECT 8 flameeffect 7 (options go here)
> > >
> > > # wipe between the two
> > > EFFECT 9 wipehorizontal 4 8 (options go here)
> > >
> > > # superimpose text caption
> > > IN 10 file 5.avi
> > > EFFECT 11 superimpose 9 10 (options go here)
> > >
> > > # write to final output
> > > OUT 11
> > >
> > > I'm not saying it's perfect (I haven't written any duration or
> > > positioning information above) but it's quite easy to expand indefinitely
> > > without getting complicated syntax, and it is easy to backtrack from OUT
> > > to IN's to figure out what needs to be done to generate each new frame of
> > > output.
> 
> In comparing the two different ways of doing things here I think I've figured
> out where we are disagreeing :-)
> 
> My idea considers the cutting list to be a description of what needs to be
> done, and which effects need to be applied, and nothing more - optimisation
> of the cutting list (like knowing when a file can be kept open from one piece
> of output to the next to avoid unnecessary seeking) should occur within the
> cutting program itself. This means more work in the cutter program (it will
> have to optimise the cutting process itself), but less work in the program
> which generates the cutting list.
> 
> Your idea considers the cutting list to be more "all in one" - that the
> cutting list is already optimised by the time it reaches the cutting program.
> This cuts down on the work that the cutting program has to do (it can just
> follow the cutting list blindly), but adds work to the program which
> generates the cutting list.
> 
> The problem that I see with optimising within the cutting list generator is
> that the program will not know what cutter it is designing the list for - it
> will know a few simple paramters so that it knows if it can use preview files
> within the cutting list, for example, but it will not know the specifics of
> the hardware that it will be generating the cutting list for.
> 
> Is the hardware capable of holding so many files open at the correct place?
> Memory might be an issue, otherwise, why couldn't we just open every file
> that we needed right at the beginning of editing and keep them open until the
> end. Perhaps it is possible to generate each seperate "chunk" (here, a chunk
> would be the output of the diagram from the previous email, and would be
> followed by another "chunk" which would have a different rendering diagram)
> of output in a different order which makes better use of the hardware, and
> then patch them together later. Of course, this can't be done as easily or
> quickly with VCR machines... but which part of the program should know about
> it - the cutter program, which has been designed to work with and interface
> with the hardware in question, or the cutting list generator, which is
> designed to be as generic amongst cutting programs as possible?
> 
> If you review the two different syntax's we are using, the structure is very
> similar. The only question is - should pipes and files be explicitly opened
> and closed, or should this be left to the cutting program's discretion, which
> could very well have a better idea on how to optimise them.
> 
> Another problem that I see with specifically optimising between chunks is that
> it makes it more difficult to tell the cutter "preview this chunk" - we would
> either need to construct a specific cutting list for generating the preview,
> or the cutter would need to "backpedal" to a previous chunk, calculate where
> the file it needs were opened, calculate where they need to seek to (since it
> will have been "played" a certain amount by effects within those previous
> chunks) and then get on with actually playing the chunk.
> 
> I'm not saying that's not possible, I just think it would be an arse to
> program :-)

Well I think I understand now what you mean, but I still would use
another syntax.

I'd use something like this then:

open test.avi a
open test2.avi b

Output
  Fade
    Start 10
    Stop 20
    Video1
       Someeffect
         file a   
    Video2
       file b

Well something like that, the exact syntax has to be determined yet, but
it should be hirarchial

Ohh BTW, sorry for the short e-mail I hope I didn't skip to much
important, I'm going to write some politics about the european DMCA
plans.

> --
> Jason Wood
> Persistence is a virtue

Servus
  Casandro