[Kdenlive-devel] edit file format draft1

[Christian Berger]

Jason Wood schrieb:
> 
> On Monday 06 May 2002 1:10 pm, Christian Berger wrote:
> > Jason Wood schrieb:
> > > >  open_output                  : sets the file for output
> > > >    Params:
> > > >       -filename               : filename
> > > >       -sizex                  : width of image in pixels
> > > >       -sizey                  : height of image in pixels
> > > >       -nativesize             : yes=keep frames in size of possible
> > > >                                 no=scale all frames
> > > >       -type                   : type of file (avi, mov, mpg, etc)
> > > >       -fps                    : framerate
> > > >       -nativefps              : yes=keep original framerate
> > > >                                 no=don't keep framerate
> > > >       -videocodec             : type of codec
> > > >       -nativevideocodec       : yes=keep native codec
> > > >                                 no=recompress all contents
> > > >       -soundrate              : samplerate of sound
> > > >       -nativesoundrate        : yes/no
> > > >       -soundformat            : format of sound (8bit, 16bit, uLaw,
> > > > etc) -nativesoundformat      : yes/no
> > >
> > > I think that videocodec and soundcodec might be better off as seperate
> > > commands, which are then referenced by open_output. The reason for this
> > > is that different codecs will have different options. By seperating them
> > > out, we make the file a little cleaner.
> >
> > I wouldn't do that, since I already need most options at the start of
> > the encoding.
> 
> How are you thinking of handling extra video codec options, such as e.g.
> compression, smoothing, etc. that might crop up in different codecs?

Well most coceds already want that as a single string, so I'd do it as a
single parameter. After all, when we open the output file we already
have to have the values for all parameters, so we have to have it
somewhere here

> > > >  seek                         : seek to a certain position
> > > >       -file                   : identifier of file opened
> > > >       -absolute               : seek to absolute position in ms
> > > >       -relative               : seek to relative position in ms
> > >
> > > Although obvious, a note should be made that only -absolute OR -relative
> > > can exist in a single seek command, or an error should be thrown.
> >
> > Uhm, why? Why shouldn't I first seek abolutely and then relatively in
> > one line?
> 
> Well this file will normally be generated by a seperate program (which can
> calculate the relative offset itself), which makes the functionality a little
> redundant. Secondly, it might get confusing : if you have the command :
> 
> seek -file 1 -relative +4:00 -absolute 2:00
> 
> Should that first move relative to the current position, and then move to the
> absolute position (effectively making the relative command redundant), or
> should it seek to the absolute location first, and then seek to the relative
> location (which makes sense, but is not expressed clearly by the line given.

It should first seek the relative position and then the absolute one,
even if it seems redundant. But if order is important all things are
evaluated left to right. We have the same problem here:

1 mosaik -size 4 -input -side 8

should the size be 4 or 8? It shurely should be 8 because that's the
last value it's set to.
 
> Finally, I can't see any particular reason why doing an absolute seek followed
> by a relative seek would be advantageous over a single absolute seek which
> does both.

Imagine you have a rather simple cutting list generator. For example
imagine a situation where you edit with tapes, all tapes have headers
before their recordings. Now you not only want a normal edit, but one
which contains all he raw material with the headers. You could then
simply add a -relative -1000ms param after every seek command. The
actual cutter however might optimize this somehow.
 
> > > > Scene definition:
> > > >  scene_start                  : command to start a scene
> > > >   Params:
> > > >       -duration               : duration of sceene
> > > >       -name                   : name of scene
> > > >       -based_on               : name of scenes which this scene
> > > >                                 is based on (usefull for clusters)
> > > >                                 may apear multible times
> > > >
> > > >  Several lines with connections. The output reads from connection 0.
> > > > All connections (which may contain effects) are only called once per
> > > > frame in an order which makes sense. Scenes also are usually executed
> > > > in order, but might be executed in parallel.
> > >
> > > Am I correct from this that only one output may exist at once? That's
> > > fine, but a line should be added saying that if an attempt is made to
> > > open a second output, then the command will fail and an error will be
> > > thrown.
> >
> > Well you cannot open outputs, the output of the scene is simply the
> > output of line 0
> 
> What about the open_output command defined above?
>
> If you ever try and make a second conflicting open_output command it should
> return an error.

Well hmm, I think all the output of a sceene should get throught the
sceene. So the only position where it may make sense to define the
output is at scene level or higher. Since there can only be one output
per scene it makes sense to use line #0
 
> > > >  scene_stop  (no params)
> > > >
> > > > Colors:
> > > >   #rrggbb (like in HTML) or
> > > >   #aarrggbb (like in HTML, but with added transparency)
> > >
> > > I think this as good a place as any to mention this point :
> > >
> > > I think that any parameter which can be set between 0 and some maximum
> > > value should have that maximum value set to 1.0, and that scaling should
> > > occur within the cutter. This makes it easy to modify the resolution of
> > > the parameter at a later date, as well as simplfiying any scaling
> > > operations that may need to be performed on the value.
> >
> > True
> 
> > > Another important point is that if we are doing linear interpolation
> > > across these values, then we _need_ to work in floating point anyway to
> > > avoid rounding errors between scenes. I can explain this in detail if you
> > > don't understand why this is so, but it's a little lengthy so I'll
> > > refrain for the moment.
> >
> > No, I don't understand why we should use floating point (bleah), why
> > aren't 32bit integers for each component enought?
> 
> Well, if we consider floats and 32bit integers to be of the same precision,
> then none, except that floats are easier to work with (to scale you simply
> multiply by whatever maximum value you eventually want, whilst with a 32 bit
> integer you would have to divide & multiply)

Floats are _slow_ and only few processors support them properly.
 
> The problem would be seen more if you picked values like e.g. 0-100 or
> something. If we are linearly interpolating from one value to another, and
> there are several scenes inbetween (like in the picture here :
> http://www.uchian.pwp.blueyonder.co.uk/roundingerror.jpg) then without using
> floating point we have to round to the nearest value at the beginning/end of
> each scene. This causes the interpolation (which should look like the purple
> line) to end up scewed like the red line, due to the rounding at the
> beginning/end of each scene. This causes small errors in how we render each
> frame (in this case, the two red dots, representing effect values are
> displayed instead of the blue dots representing the correct values.

I'm sorry, but that image seems to be corrupt
 
> Of course, floating point itself will have some small precision errors due to
> rounding, but I haven't looked into them in any great detail :-)

Well I think integers would be sufficient.
 
> > > Anyway, color is one such value that should be set from 0-1, including
> > > fade (as you have already set from 0-1 below), other transitions and any
> > > other effect with a "maximum" value.
> > >
> > > Because of all t his :-) I think color would be better represented as
> > > either :
> > >
> > >                 RGB( redvalue, greenvalue, bluevalue)
> > >                 RGBA( red, green, blue, alpha)
> > >                 ARBG( alpha, red, green, blue)
> > >                 -r redvalue, -g greenvalue, -b bluevalue -a alphavalue
> > >
> > > The top three are better ways of representing color, as they would allow
> > > us to represent color using other colorspaces, for instance HSV.
> >
> > How about RGB,0.4,0.1,0.4 ? This would be easier to parse.
> 
> I'm not sure it will be that much easier : to parse the RGB() one, you would
> do something like this :
> 
> if(next piece of string is RGB) {
>         while (next character is whitespace) move along a character
>         if( character isn't a '(' ) return an error.
> 
>         read first value, until we reach a character which can't be parsed as part of
> a number.
>         while(next character is whitespace) move along a character#
>         if( character isn't a ',' ) return an error.
> 
>         // repeat the last three steps for each value, except for the last one, where
> we replace the test for a comman with a test for a closing bracket.
> 
>         repeat for next value.
> }
> 
> Consider that whitespace test becomes a function call, reading a number
> becomes a function call, and the character tests are simple.

Well I think parameters shouldn't contain whitespaces, otherwise we
don't know this is only a single parameter, since parameters are
seperated by whitespace, too. However for texts we need Quotes for
enclosing string, but this is general.
 
> Jason Wood
> I knew I needed a break when I tried to close konqueror by typing <Esc>:q!

Servus
  Casandro
 
> _______________________________________________________________
> 
> 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