Jit.qt.movie fps serious problem
I'm trying to create a patch which at final output renders a quicktime movie, these movies will for the most part be rendered at their native fps without any variation in their playback "rate" whilst in the patch, it's important that the final frame count and rate remain accurate and at an exact match to the source movie, without either dropping or repeating frames. ie is frame accurate.
So, I've started putting together the basic elements in to a patch and am having the following problems, the fps of the playback and record windows does fluctuate slightly as indicated by the fps objects, though minor it's obvious that this frame rate is not "locked" and when I hit the write message the frame rate drops to approx 10 fps slower, completely dislocating it from it's original frame rate and order, which creates choppy looking renders with frames both duplicating and dropping out.
I can't find any way to fix this problem, I'm new to maxmsp and jitter and I'm not sure a lot of the time if I'm working around genuine bugs or my own errors, it would be a great help to me to talk this though with someone.
Richie.
looking at this some more, if it cant render 30 fps accurately then how could it ever handle 29.97, this is an industry standard playback rate making maxmsp's video capability far bellow industry standards lets face it, with 30 fps footage loosing 5 to 10 frames a second in maxmsp there's not much of an option for us, is there/
Say you've just finished rotoscoping 3000 frames of footage, it's taken you about a month, this footage now will be further treated in Jitter currently Jitter rendering is dropping 10% of it's frames so jitter would loose aprx 300 of those frames on render, a lot work to see just get thrown away.
(please feel free to prove me wrong)..
try the "realtime" message to jit.qt.record, this should do it (won't drop frames but may take longer than realtime to render the whole movie, which is OK in your case). check the documentation for info, I think it's designed for exactly this.
Indeed, I've included it in my patch patch posted above, I'm afraid it appears to still render in realtime with no better stability.
I think the footage is already drifting before it reaches qt record..
I feel the clock source used for playback of the video is the real issue here.
qmetro's clock stability is affected by other events and the priority that both max and the system place on these events. There's some parameters you can change about the scheduler to help you, but I can't forsee ever reaching the stability you desire.
I hope more will weigh in, this is always a tricky topic.
Success.
Blimey my faith in maxmsp was really starting to dwindle there for a minuet but there is a solution in the help file, don't know why I missed it.
My apologies for assuming the worst, it's my experience that a lot of AV apps out there are missing this rendering function and are in the main focused on live performance I feared maxmsp would be the same.
For anyone searching for "frame rates" or "fps" experiencing problems in the future look at this "offline" rendering engine as an alternative , it works in a similar way to traditional video apps like Adobe AE, Premiere etc, I missed it taking it to be just a frame dump but it's also a renderer and can be found at the end of the recording qt movies help section.
Haven't figured out how to patch the audio in to the qt movie yet but here it is :D
but why???
Do you mean why does the patch render without audio?
Oh, that's not the whole patch lol. no it'll have a timeline that sequences loops and all that stuff that jitters, like a little video editor/looper app but I wanted to tackle this problem of rendering before I got in to building the rest of the patch, which I'll work back from here. it wouldn't be worth building my patch if it couldn't render and also I don't know maxmsp well yet.
I'd be very grateful for any help or ideas.