[Kdenlive-devel] Cutting list file format specification, Version 0.02

[Christian Berger]

Jason Wood schrieb:
> 
> Hi,
> 
> After getting completely bogged down in exams again, I've had a few spare
> moments to update the cutting list specfication now.

I know how you feel, in 3 weeks my final exams will be, well actually,
they will be kinda semi-final since I'm going to another class
afterwards.
 
> I've incorporated the changes that we discussed, and came up with a couple of
> other things which we hadn't thought of before.
> 
> Firstly, I have said that each cutting list should start with a version
> command. This is important so that we can add new features, and modify stuff,
> and know what to expect for any particular version.

Well I don't know if we'll ever need it, but it sure is an interresting
piece of information. Maybe we should also define a "creator" command,
telling us which programm created the cutlist. Maybe also a date and
comment field. Those fields definitely are good for recovering broken
harddisks :)
 
> Secondly, I have added a couple of extra parameter value types - String, ID,
> and time and interpolation. We need to decide exactly on how time should be
> represented within the file format.

Well I'd say we use time in milliseconds. Unless we want to be limited
to film and PAL/SECAM we have to be able to handle wiered framerates
which aren't a multiple of 0.01. We cannot really do that with
00:00:00:00 formats.
 
> Thirdly, I have added the interpolation concept. Whilst at the moment it is
> limted to simple interpolation between a start value and an end value, the
> idea is that the interpolation within a scene should be independant of the
> values it is working on : instead of having -startvalue -endvalue, we have
> just -value which can accept an interpolation. Whilst slightly more difficult
> to parse (though not greatly more so), it allows for a great degree of
> freedom for later expansion. E.g. we could at a later date expand it to allow
> non-linear interpolations, or to have "freehand" sets where the value changes
> randomly.

Well I'd do it a different way, I'd do "0 1 linear" Althought this
doesn't seem to be much different (now it's encoded in a string) it
might mean a lot of flexibility. We could write a tiny little Forth
interpreter. This interpreter would interpret the "interpolation" at
every frame. On the stack there already will be the current relative
time of the scene as well as the length of the scene, and the command
"linear" calculates the value based on start and end values. For example
if we want to make a linear wipe going in steps we could do this:
0 1 linear 5 * int 5 / which would let it move in 5 steps.
 
> Fourthly, I've re-structured the document, and used Star Office to write it.
> Unfortunately, there seems to be a problem with exporting PDF files at the
> moment - the file is now on the website, but only seems to be viewable using
> gv. I'm still trying to figure out what's going wrong. I also intend to add
> an HTML version sometime soon.

Well it looks quite well for a PDF file.

On page 1 below the drawing there's a typo, scehduler should be written
scheduler, I think.
Scenes also can have a length of less than a frame. This might be
important if you want to "fill up" scenes.

Maybe we should somehow distinguish between file IDs and connection IDs
since I have to have a "list" of all the files beeing used in a scene

Well about the smoothing input of the croma effect (I'd call it
cromakey) How would you define it? I mean it'S a color value.
Maybe we should try something like this: A forth effekt. The same
interpreter used in interpolation could calculate the whole effect.
It would be called for every pixel and it get's the pixel values of the
incoming images on the stack and leaves the outgoing pixel on top of it.
When done efficiently that wouldn't be to slow.

> Fifthly, I changed a couple of names and definitions, such as changing
> open_input to define_input, and open_output to define_output.

Sounds good
 
> Sixthly... Umm.. I think that's it for now.
> 
> Take a look and let me know what you think.

I think it's mostly OK :)

Servus
  Casandro
 
> --
> Jason Wood
> I knew I needed a break when I tried to close konqueror by typing <Esc>:q!
> 
> _______________________________________________________________
> Hundreds of nodes, one monster rendering program.
> Now that's a super model! Visit http://clustering.foundries.sf.net/
> 
> _______________________________________________
> Kdenlive-devel mailing list
> Kdenlive-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kdenlive-devel