Generally, Moing should be pretty forgiving about frame rates. If you want to place a 15fps clip or character animation in a 30fps project, it should let you do that. If the framerates aren't exactly multiples, then you aren't guaranteed great results as frames will be held or dropped, but it should still work and the timing should come out right. Similarly, you shouldn't be required to match audio sample rates to the project rate (though, again, you will get the best results if you don't make Moing resample on-the-fly).
The timing of events should probably be stored as a rational, with the frame number as the numerator and the framerate in effect when the event was created/positioned as the denominator. That way, you can keep your timing across framerate changes without doing hard re-quantization.
We should directly support the NTSC frame rate of 29.97 frames/second somehow. It's ugly, but it's a fact of video. One way would be to multiply the numerators and denominators by 100, so e.g. PAL frame numbers would be over 2,500, and NTSC frame numbers over 2,997. If we're using Haskell Int for our rational numbers, that comes out to about 50 hours before our numerator rolls over. That... should be enough (famous last words).
The design and implementation of an Open Source animation tool.
July 2, 2007
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment