[Kdenlive-devel] Survey among filmmakers

[Christian Berger]

Servus

I've done a little survey among filmmakers (actually just one) on what
effects they'd like to see:

You page, "As you might know, I'm in the development team of a video
editing
programm, and now it might be nice to know what filmmakers want and what
not"
to CirrusKitfox.
CirrusKitfox pages, "Well, one thing I've always wanted was the ability
to
create title sequences over running video without a lot of effort." to
you.
You page, "Those long scrolling titles?" to CirrusKitfox.
CirrusKitfox pages, "As well as fading titles." to you.
CirrusKitfox pages, "It can be done with Adobe After Effects, but it's a
pain." to you.

Ohh and he also wanted it to be able to read MPEG, but I explained him
this is still a bit down the road.


I've done a draft on out internal video-format (also audio, seperate
files):

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

I don't think I really have to ask, but what do you think of it?

Servus
  Casandro