jit.qt.record bug – wrong speed/movie length – analyzed
Last night I discovered a serious limitation/bug with jit.qt.record (I need realtime = off). As described also by several persons in this forum the resulting movie’s play framerate does often not correspond to the settings. I discovered that it depends solely on the x/y resolution settings in the jit.qt.record object! Nothing to do with codec or recording from jit.matrix or jit.gl.asyncread or correspondence of source x/y resolution with record resolution. With higher record resolutions the movie plays at a higher speed! In my case I’m recording in a 25Hz environment (metro 40, jit.matrix + jit.gl.render) duration 20 seconds. Here a list of measurements:
jit.qt.record settings -> resulting movie file duration
1280 x 720 , 25.0 Hz -> ca. 10 sec. – too fast – double speed
800 x 448 , 25.0 Hz -> ca. 12 sec. – too fast
640 x 480 , 25.0 Hz -> ca. 13 sec. – too fast
320 x 240 , 25.0 Hz -> ca. 20 sec. – correct speed!
1280 x 720 , 12.5 Hz -> ca. 20 sec. – correct speed!
320 x 240 , 12.5 Hz -> ca. 40 sec. – too slow – half speed!
Got it?! As stated above the environment conditions have NO meaning. Everyone can try the effect by simply running and editing the jit.qt.record MAX 6.0 built in help patch. Just edit the ‘jit.qt.record 320 240′ object changing the x/y resolution. Use ‘countdown.mov’ for ease of verification.
MAX 6.0.1 (50928) on Windows 7 and Intel i7 processor 2.8 GHz, 8 GB RAM
So is this a Quicktime bug or something wrong in the MAX object?
Does it happen only under Windows?
I repeated some test with longer recording times. The resulting speed is NEVER really precise! So audio synch will be impossible.
Did you ever find a solution to this, other than changing dimensions? I am having the same problem on a mac machine so it’s not only windows.
If you are not using the object in ‘realtime’ mode, you have to ensure that the object receives the correct number of frames for the desired framerate. That’s essentially what realtime mode does, but if you’re working with "slow" (e.g. big) media, you’ll have to construct this architecture yourself using Max.
Thanks, that clears some things up. Is there a certain codec that is generally used for big media? One of my main problems is that as soon as I start to record, my fps drops by about half. As I’m using jit.phys objects to trigger audio events (which are routed through kontakt back into max via soundflower), non-realtime is not really possible. I’ve attempted this with both jit.qt.record and jit.vcr, both in and out of realtime mode. Is the recording itself really putting that much of a strain on the machine? I’m attempting to record 1280×720 @ 30 fps, with 2 channels of audio, surely this achievable. Things run relatively smoothly as soon as I stop recording.
It’s going to be a combination of disk access speed and compression overhead. With an SSD drive you can likely eliminate much of the former. Randy Jones had a very useful patch called "render_node" for managing NRT recording. But it’s unfortunately no longer online (and I don’t have a copy lying around), and I doubt it would be too useful in the interprocess audio case.
What does Blackmagic’s disk speed test tell you about your HD speed? http://itunes.apple.com/de/app/blackmagic-disk-speed-test/id425264550?mt=12
For reference, my Mac Pro/2.66GHz Quad/10GB w/ normal ATA HD can only write PAL and NTSC at full speed. My MBP with SSD can read and write 10-Bit media at sizes up to 1080i. 1080p is too heavy.
12-bit media is limited to PAL and NTSC.
I Have the same problem recording 1920×1080 videos in max. When i playback the videos they are much more faster. Have anyone successful record this dimension videos without this speed issue?
The machine I’m using doesn’t have an SSD, and according to the disk speed test can only write PAL and NTSC at full speed as well. So then hypothetically if I attempted this on a machine with a SSD much of the burden would be lessened? If I may ask, what kind of transfer speed are you getting to write 1080i in real time? Just so I know what to look out for if I end up purchasing an SSD.