Any recent beta (but prolly going back a ways), included JRE 1.6, WinXPsp3.

When creating an instance of MovieMaker at a specific 30 fps rate, the output movie
is actually produced at 30.3 (as reported by QuickTime player, for example). Such
that a 300 frame video is only 9.27 seconds in duration, rather than 10.0 seconds as
expected.

By contrast, a movie created at 25 fps is reported as exactly 25.0 fps (and duration is
as expected from a given number of frames)

FWIW, the cause appears to be the use of "100" as the timebase value
(aka "timeScale") in MovieMaker.java, which divides nicely for 25 but not for 30. A fix
might be (?) to instead use 600 as the time base, so that more of the "common"
frame rates are evenly divisible.

Some further info:
My compile environment is currently hosed, but... I pulled MovieMaker.java out and
inserted it into a plain sketch (by removing package statement), then modified the
TIME_SCALE constant at top to 600, and verified that output .mov created with this
local derivative of MovieMaker is reported as exactly 30.0 fps by QuickTime player.
Same movie created instead with processing.video.MovieMaker (that uses
TIME_SCALE=1000) produces 30.3 fps output.

I think how it works is (apologies for stating the obvious if you already know this!!)
QuickTime divides a second into TIME_SCALE tick units, but each frame is only an
integer number of those ticks. So a requested 30fps needs 33.333333 ticks per
frame, but rounded to 33 integer ticks. So with 1000 integer ticks per second,
playing each frame for 33 ticks, the actual playback rate is 30.3030303030... frames
per second. But with 600 ticks per second, each frame gets exactly 20 integer ticks,
so when played back is exactly 30fps.

600 seems (?) a "nicer" value since 20,24,25,30 would all divide into it.

thanks for looking into it. did you pick 600 because it seemed useful or is
that a recommendation w/ quicktime or video stuff (the number comes to mind
as familiar, like i've seen it in other qt movie stuff).

the research i did was quick, but 600 kept turning up, for example:
http://developer.apple.com/quicktime/qttutorial/movies.html#TimeScale
(that wasn't the exact site i had found before, but it was similar and also from
apple.com)

the 600 base won't do 29.97 NTSC drop-frame (which requires it's own custom time
scale) but i doubt it'll ever be missed (especially since the api doesn't even OFFER
float fps), but it covers all the most common ones.

k, thanks. i've changed it for 0155, please give it a try with the current
svn to see how it's working.