[Kdenlive-devel] edit file format draft1

Sat May 11 14:10:11 UTC 2002

Jason Wood schrieb:
> 
> 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.

Good

> > 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 how about "Parameter out of bounds (32)"?

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

Yes, but some cheap gernerators might create such lists, but I think a
warning or notice might be good.

> Order of parameters should not be important.

Well we might hit a situation where we might need it, but at the moment
I cannot think of one.

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

Well what if we have programms wanting to edit the "cutlist" directly?
Then we might get into those situations.

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

Well we should have open_output and close_output commands. That way we
can generate several files with one "cutlist".

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

Sure

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

All the exterman numbers should be between 0 and 1 (1 theoretically
excluded, but still interpreted as brightest)

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

I think I know what you mean.

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

Well we can use floatin point notation in the cutting list (my parser
might read it out into integers then :) )

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

OK, now somebody needs to make a new version of the file format, maybe
it's your turn now :)

> Cheers,
> Jason

Servus
  Casandro

> --
> Jason Wood
> I knew I needed a break when I tried to close konqueror by typing <Esc>:q!
> 
> _______________________________________________________________
> 
> 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