[Kdenlive-devel] File format definition

[Jason Wood]

On Saturday 06 Jul 2002 7:43 pm, Christian Berger wrote:
> Servus
>
> Uhm do you still have the file format definition I posted? I tar.bz my old
> mail and I'm to lazy to unpack it again :)

Is this the one you mean?

>>> original message below <<<

The files consists of lots of equal sized blocks each looking like this:
blocktype: int 32  
timecode:  int 32 (timecode in ms)
blockno:   int 32 (0 for first block
datasize:  int 32 (number of octets in this block)
data       data till block ends, otherwise filled with binary zeroes

Well now the first block in the file is the header:
  blocktype= some value (maybe binary "KDEN")
  timecode = some value (maybe binary "LIVE" so the header will say
KDENLIVE as a magic number)
  data:
    version:  int 32
    creator:  string 4 (some short string indicating the creating
programm)
    blocksize: size of blocks (I know this is a hack)

Well then there are a lot of video blocks:
  blocktype= some value (maybe binary "VIDE")
  timecode= timecode
  data:
    width: int 32
    height:int 32
    format:char 8
     imagedata
   width and height are there to make it easy to get the framesize to
decide on stuff like resizing.
   the imagedata contains the image

And there are audio blocks:
   blocktype= some value (maybe binary "AUDI")
   timecode= timecode
   data:
     samplerate: int 32  (samplerate in Hz *256)
     channelbitmap:int32 (bitmapped channels)
     format: char 8
     samplecount : int 32 (no of samples)
     reserved    : int 32 (padding, should be 0)
      audiodata
    Well we have 32 channels, but not all of them are stored in a block,
so every bit in the channelbitmap value represents a channel, if a bit
is set, we get data from the audiodata, if not we don't, so if 2 bits
are set, we expect audiodata to give us 2 channels)

And then there may be a frame after the header (directly after) with
some data indicating some comment stuff.
I'm not to sure about the format of it, but it'll probably contain a lot
of 32bit Unicode strings.


As you can see, the file is alligned to 64 bits, even those 8 char
strings perfectly could be read as an int64 (or whatever thing there is
in C). The blocksize should be a power of 2 as well as just large
enought to hold a frame. (or a multiple of it holding a frame)

For the image data, we'll first definine some primitive data types, for
example:
format: "RGBA_RAW" will contain data in RGBA format 8 bits per value,
uncompressed

format: "S16B_RAW" will contain data in Signed 16bit format, in blocks
of samplecount length, one channel after another
                        AAAAAAAAAAABBBBBBBBBBBCCCCCCCCCCCCDDDDDDDDDD
(etc)


blocks are "valid" for the time after the timecode
              
AAAAAAAAAAAAAAAAAAAAAAAABBBBBBCCCCCCCCCCCCCCCCCCCCCCCCDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
|                       |     |                       |
timecode A              timeB timecode C              timecode D