[Kdenlive-devel] edit file format draft1

[Jason Wood]

On Friday 10 May 2002 9:08 pm, Christian Berger wrote:
> Jason Wood schrieb:
> > 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

Fair enough.

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

Surely it should give an error - too many parameters :-)

Or at least a warning "parameter hidden by second parameter", but if this was 
generated by a cutting list generator, then it is a bug in the generator (in 
which case sending an error from the cutter makes it easier to debug), and if 
it was hand crafted by a human... then again it has to be a bug. There is no 
reason why one parameter shold exist if it get's hidden straight away by 
another parameter, giving no access to the original.

Order of parameters should not be important.

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

If it is the cutting list generator creating the file, then it will still be 
able to handle this itself, and if we are considering using e.g. sed to 
modify the file in a script, then it wouldn't be any harder to add a second 
seek on a seperate line. As far as the cutter is concerned, it can still 
optimise this in exactly the same way.

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

I was talking about at higher than scene level - I mean, that between scenes 
you shouldn't be able to define more than one output at a time :-) If you 
can, then they would need to be given an ID, and each scene should recieve 
"Output ID" as a parameter so that it knows where to output it's stuff to.

But I don't think that a cutting list should be able to send stuff to multiple 
outputs - for that you really should be using multiple cutting lists, so I 
think an error on attempting to open a second output makes sense.

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

Remember that these float (or double) values don't need to be used internally 
to the cutter if it doesn't want to - in that case you only have to deal with 
floats at the beginning/end of each scene, it's not in any inner loops and 
optimisation of it is pointless. 

Consider also the problem for generating a cutting list which will be used on 
both 32 bit hardware and 64 bit hardware. Should we limit integer precision 
to 32 bit so that it works on both, or do we make seperate cutting lists to 
work on each? The first means that we are not making full use of the 64 bit 
processor, the second means that the cutting list is not cross-platform.

With floating point, all numbers are between 0 & 1, so we never have to worrk 
about what MAX_INT happens to be on a specific system. As long as the cutting 
list generator makes the numbers as precise as necessary, (1024 bit floats? 
mmm!) then the cutter can just take them and use them as precisely as it can.


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

Doh, works fine here & in gimp, but I've made a .png out of it here :

http://www.uchian.pwp.blueyonder.co.uk/roundingerror.png

It's 7 times the size, and I didn't keep the original image I made, so it's 
still got all the compression artifacts that jpg adds but hopefully you will 
have more luck with it.

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

See above. You can still use integers internally to the cutter, but use 
floating point in the cutting list file.

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

Ok, forget the whitespace from above.

Cheers,
Jason

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