audio/video record at highest rez possible
Jan 4, 2007 at 6:04pm
audio/video record at highest rez possible
i’ve been using jitter for about 6 months, and this is my first post to the list.
i have a patch that uses peak~ to trigger plume and brcosa effects to the video of the same mov. in addition, 3 interweaving decay functions also feed the plume and brcosa objects so that the effects build, flow and ebb over time.
i’m having a hard time finding the best way to record the output of this patch with:
-1) as high resolution as possible
i’ve tried realtime and framedumping with both jit.vcr and jit.qt.record/sfrecord~ as well as audio out with spigot~ and with soundflower.
it works best with the qt rendered at 320×240 in photo-jpeg at 15fps (as stated in the jitter manual appendix), but i’m hoping to get as close to 720×640 as possible. i’ve had limited success at higher resolutions, frame rates, and codecs. the mov is long- about an hour, so it takes a while to create variations.
i’ve yet to record directly out to a deck, try to loadram or buffer the movie, or split the video and audio sources apart.
until someone points me in a firm direction, i’ll slowly attempt each solution, but i could use help.
hopefully, there’s a dumb simple solution that i just don’t know about.
sorry for the long first post. i’m running max 4.6/jitter 1.62 on a 2.7ghz g5.
ps- i just read about 1.63b, so i’ll try that as well.
thanks in advance.
Jan 4, 2007 at 10:38pm
Our method is to write only the parameters of every effect we use into a coll during a low resolution record stage, then render them back frame by frame (non-realtime) in a next stage, at as high resolutions and framerates as you wish.
During the low resolution recording stage, put max in overdrive and make sure you use a qmetro for your video output and a metro for the parameter recordings.
Not a very elaborate description but hope it helps,
Jan 4, 2007 at 11:05pm
i get the idea. thanks for the tip. i’ll let you know how i do.
Jan 5, 2007 at 2:40am
This sort of question came up at in a recent Jitter course that I attended, and the answer was to record to an external recorder via S-video output (everyone in the class had powerbook/macbook with S-video output). Writing to the hard drive is the weakest link on many personal computer systems.
Jan 10, 2007 at 7:00am
“During the low resolution recording stage, put max in overdrive and make sure you use a qmetro for your video output and a metro for the parameter recordings.”
i think i understand the logic behind the qmetro, but why a separate metro for the parameter recordings? i want one reading per frame of video don’t i?
please take a look at the simplified patch enclosed. i’ve set it up with the crashtest mov that comes with the max application for illustration sake. i’m actually testing my patch with a 640×480 version of an hour long video i’ve put together.
in the low rez pass patch, i tie the parameter recordings to the qmetro and qt unit of the mov. this means that with every bang from the qmetro, a gettime message is sent and this elapsed mov time becomes the index for the coll reading. during the high rez pass, every bang cooresponding to a frame from framedump should send a next message to the coll object. this triggers the retrieval of the next parameter reading which gets passed to an effect object (plume in this case).
in my simplistic logic, this seems like it should work, but something is off because the hi rez pass results in frame accurate video, but the coll recordings only play partly through.
the coll time index (which is expressed in qt units) ends about 10k units short of the mov after the framedump of an hour long movie.
also, i eventually want to render out at hdv specs, but even at 640×480, my output is currently a whopping 40 plus gigs.
any suggestions on bringing the effects closer in synch with the audio as well as streamlining the resulting video would be appreciated.
sorry for the unweildy post. thanx in advance for the help.
Jan 10, 2007 at 10:09am
To chime in here, the problem could be in “lost” messages to coll.
One solution I use is a gated record using [onebang] to guarantee
On Jan 10, 2007, at 7:01 AM, t ozawa wrote:
> Mattijs wrote:
Jan 10, 2007 at 10:54am
Quote: bokemono wrote on Wed, 10 January 2007 08:00
I understand your confusion. It looks like there is a fundamental mistake in your understanding of how jit.qt.movie works. It looks like you assume that it outputs all frames it contains one by one. This is not the case. Very short: it has a timeline that runs independently of the loaded movie and only when you send it a bang it chooses which frame to output.
It is important to consider that you can’t rely on the output of a jit.qt.movie to be constant. The idea behind qmetro is that it outputs as much bangs as possible considering the space on your cpu (read more in the jit.qball help and about max threading in general). If you use this mechanism to record values to your coll, the amount of entries per second will vary over time. Metro on the other hand interrupts all other processing (when max is in overdrive), so records your parameters as accurately timed as possible.
In the recording stage
In the render stage, do this for each frame, in the following order:
note: in the render setup, set jit.qt.movie to rate 0. You don’t need its time functionalities, you only need the separate frames of the times that you recorded in your coll.
note: jit.qt.record has to write the output file in a format with the same framerate as the metro used to record to the coll in the recording stage (see what this implies? There has to be a fixed framerate somewhere. That’s why you need the separate metro.)
That’s a nicely simplified patch. If you wouldn’t have included it I couldn’t have given you this reply. :)
that is 640×480 (pixels) x 3 (bytes) x 15 (frames) x 60 (seconds) x 60 (minutes). Seems correct to me. ;)
Consider photo jpeg at high quality or any other codec that does compression.
np, I hope this helps.
Jan 10, 2007 at 6:54pm
thanks so much. this is great info.
i was confused about the role of qmetro in the equation. i also didn’t understand that metro in overdrive provides the steadiest stream of bangs. i thought i understood the stability provided by qmetro, but i need to grasp it better.
>- also record the movie time to your coll (note that gettime >will give a different value even if you didn’t send the jit.qt.movie a new bang)
is it okay to continue making the movie time the coll index or is there a reason not to?
>note: jit.qt.record has to write the output file in a format with the same framerate as the metro used to record to the coll in the recording stage (see what this implies? There has to be a fixed framerate somewhere. That’s why you need the separate >metro.)
gotcha. the coll metro rate becomes the reference rate. makes sense.
>That’s a nicely simplified patch. If you wouldn’t have included it I couldn’t have given you this reply. :)
thanks! it’s the least i can do for all the info.
>that is 640×480 (pixels) x 3 (bytes) x 15 (frames) x 60 (seconds) x 60 (minutes). Seems correct to me. ;)
i guess if i did the math first i wouldn’t have been caught off guard:)
thanks again. let’s see how i do.
Jan 11, 2007 at 9:42am
Quote: bokemono wrote on Wed, 10 January 2007 19:54
In your case it shouldn’t matter because you play the movie linearly. Maybe one day you’ll do real-time cuts in your movie ;)
You must be logged in to reply to this topic.