Kurt from AUVI software wrote this insightful tidbit on Jitter framerate. I was having issues with my videos stuttering.

jit.qt.movie does not “guarantee’ a frame rate: the speed it reads the file from disc is independent from the speed it outputs frames. The speed jit.qt.movie outputs frames is NOT related to the frame rate of the video file: it is only the result of how many bangs per second it receives.

If you set the metro that bangs the jit.wt.movie to “100″ you will get around 10 frames per second output. This is true if your video FILE has a frame rate of 29.97, or 24, or 15…or even if your file is a still image, like a .jpg, instead of a .mov.

Frames per second of the file is NOT EQUAL to the frames per second that jit.qt.movie outputs. It is entirely independent.

Each bang received is a request to output a frame. If it has a new frame available, it will out put it. If it doesn’t, it will output the same frame again. (This is the reason you may see an output frame rate that is higher than the frame rate of your file — you mention seeing 33.25 from a 29.97 file.)

If you want to “guarantee” an output rate, your best bet is to type “@unique 1″ on the jit.qt.movie, and set the metro faster that your intended output frame rate (say, 20ms for 29.97fps). This insures that no duplicates will be output, and that there will almost definitely be a request for every new available frame from disc.

In MSP, it’s possible to guarantee timing: when MSP is ON, audio signals flow down the yellow-and-black patch cords at 44.1k samples per second, GUARANTEED. In Jitter, there are no guarantees. Video is heavy work, and there is no way to insure that other Max activities (effects, etc) won’t bog down the processor, or that system activities won’t cause the disc to spin etc.

Kurt