[Kdenlive-devel] edit file format draft1

[Jason Wood]

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?

> > >  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.

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.

> > > 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.

> > >  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)

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.

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 :-)


> > 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.

Jason Wood
I knew I needed a break when I tried to close konqueror by typing <Esc>:q!