Monday, May 19, 2008

Frame independency, more API changes

I was rewatching the Edius Pro ads, and I marvelled at the concept of fps and resolution-independent processing. I remember the first time that I tried to import a clip in Premiere. It complained about the fps of the video being different than the current project's.

I had forgotten about this until I rewatched this promo. Wait a sec, fps-independent? Resolution independent? Cool!

Then I thought about the difficulty of such implementation. For now we can see timelines having HH:MM:SS:FF:MMM (hours, minutes, seconds, frames, and milliseconds - or was that milliframes? I don't think so.).

Currently in the timeline structures I have the tracks sorting the clips by frame. It's an integer number. But then I thought - hey, a millisecond is also an integer. So what's the limit for our videos? Let's see...

Assumming we have a limit of 2^31, we have 2147483648 milliseconds available for a production. If we divide it by 1000, we got 2147483.648 seconds. Let's round it to 2147483 seconds. If we divide it by 3600, we got ourselves an amount of 596.52 hours, which would be equivalent to 24 straight days. More than enough, I think :).

And due to the fact that we're using std::maps and not mere vectors, we don't have to worry about memory requirements: They're exactly the same.

Another thing I realized was that storing clips in a pool for later usage, is simply a waste of time and resources. Each time we copy/paste, we're gonna generate new clips. Cutting doesn't solve the problem because we could undo and yet retain the clip in the clipboard, so we'd need to process that. So, that would leave us with only more complexity and absolutely no storage gain.

If we get rid of the clips-in-storage-pool, we can store the clips (clip as in data-structure, not the movie, duh) directly in the timeline. Since it's an STL map, we don't have to worry about pointers either!

So these are the next changes to be done in the infrastructure.

No comments: