double speed of the recordings
Hi,
I am getting videos twice the speed when I record them through
jit.qt.record.
I have done many trials. Starting with the tutorials. It does not
happens with the videos in "media" from the examples. It is happening
with my own videos.
The only strange thing I am doing is that I changed the 320 240 for
720 480 in both the players and the recorder.
I produce my videos in final cut in HDV, render them to dv through
the compressor. I have also tried with videos rendered in mjpegb. I
have tried all type of the lengths.
I include no patcher since it is also happening with the tutorials.
Unfortunately videos are to heavy to send them for you to try them.
My guess is that the reason of this is in my videos.
Any clue will be welcomed. The only time when this does not happen is
when I use jit.vcr and record sound, but the present patcher is too
heavy for this...and I rather sync them afterwards.
I have all the latest max/msp/jitter (beta) and Mac-intel 2GHz and
read the videos form an external HD.
Thanks
Adina
>Hi,
>I am getting videos twice the speed when I record them through jit.qt.record.
I'm sure that this is perhaps not necessary, but my first question in a
case where the length of a recorded movie doesn't match the input
is always "are you sending the "realitime 1" message and driving your
metros at the speed that matches the frame rate you want? [e.g. metro 33.3]?
--
on the floor there's a long wooden table/on the table there's an open book/
on the page there's a detailed drawing/and on the drawing is the name I took
Gregory Taylor http://www.rtqe.net
try recording with @realtime 1 for jit.qt.record.
On May 19, 2007, at 12:04 PM, [a/izarra] wrote:
> Hi,
> I am getting videos twice the speed when I record them through
> jit.qt.record.
> I have done many trials. Starting with the tutorials. It does not
> happens with the videos in "media" from the examples. It is
> happening with my own videos.
> The only strange thing I am doing is that I changed the 320 240 for
> 720 480 in both the players and the recorder.
> I produce my videos in final cut in HDV, render them to dv through
> the compressor. I have also tried with videos rendered in mjpegb. I
> have tried all type of the lengths.
> I include no patcher since it is also happening with the tutorials.
> Unfortunately videos are to heavy to send them for you to try them.
> My guess is that the reason of this is in my videos.
> Any clue will be welcomed. The only time when this does not happen
> is when I use jit.vcr and record sound, but the present patcher is
> too heavy for this...and I rather sync them afterwards.
> I have all the latest max/msp/jitter (beta) and Mac-intel 2GHz and
> read the videos form an external HD.
> Thanks
> Adina
>
On May 19, 2007, at 9:24 AM, joshua goldberg wrote:
> try recording with @realtime 1 for jit.qt.record.
Or if you're using framedump for non-realtime recording (which I
would *highly* recommend for more steady timing in the output movie,
since realtime recording will have any framerate fluctuations your
patch experiences in real time), be sure to set the framerate of
jit.qt.record to the framerate of the jit.qt.movie instance.
Lastly, if you are using realtime record, use a metro speed that's
something like the framerate you want to record at or jit.qt.movie's
@unique 1 attribute to prevent redundant frames being sent through
your jitter network. Otherwise you are recording extra frames, since
jit.qt.record writes to disk every frame it receives.
-Joshua
Dear Joshua, Joshua and Gregory:
I used it all: the 33.3 metro for the recorder (number 2 of the
tutorial 19 on recording), the @realtime 1, and the @unique 1 for the
players.
Using only the @realtime 1 was making my patcher incredible slower!
I could not even use the "write"!
I cannot use the dump alternative since I use several presets during
the 2 min. video. I enclose the patcher (which comes form the
recipes!), maybe there is something else to be checked. I still have
to use very small videos (320 180) so it does not slows down...or get
a better computer.
Saludos and thanks a lot
Adina
On May 19, 2007, at 2:45 PM, Joshua Kit Clayton wrote:
>
> On May 19, 2007, at 9:24 AM, joshua goldberg wrote:
>
>> try recording with @realtime 1 for jit.qt.record.
>
> Or if you're using framedump for non-realtime recording (which I
> would *highly* recommend for more steady timing in the output
> movie, since realtime recording will have any framerate
> fluctuations your patch experiences in real time), be sure to set
> the framerate of jit.qt.record to the framerate of the jit.qt.movie
> instance.
>
> Lastly, if you are using realtime record, use a metro speed that's
> something like the framerate you want to record at or
> jit.qt.movie's @unique 1 attribute to prevent redundant frames
> being sent through your jitter network. Otherwise you are recording
> extra frames, since jit.qt.record writes to disk every frame it
> receives.
>
> -Joshua
>
On 19 mai 07, at 22:43, [a/izarra] wrote:
> Dear Joshua, Joshua and Gregory:
> I used it all: the 33.3 metro for the recorder (number 2 of the
> tutorial 19 on recording), the @realtime 1, and the @unique 1 for
> the players.
> Using only the @realtime 1 was making my patcher incredible
> slower! I could not even use the "write"!
> I cannot use the dump alternative since I use several presets
> during the 2 min. video. I enclose the patcher (which comes form
> the recipes!), maybe there is something else to be checked. I still
> have to use very small videos (320 180) so it does not slows
> down...or get a better computer.
> Saludos and thanks a lot
As JKC suggested jit.qt.movie's framedump is the best way to get a
real smooth recorded movie. You can recall some presets during the
recording if you need (jit.qt.movie send out the frame index via the
dumpout output). For more info you'll have to send the patch or part
of it, otherwise there's no way for us to help.
Cheers,
ej
Hi Adina,
Okay, let me make another suggestion. If you want to have patch
interactivity and can't (or prefer not to) use framedump, and *don't*
want the problems of realtime mode, you can do the following--i.e.
operate your patch in "slow motion" to account for the expense of
processing and writing to disk:
1. make your movie playback speed as slow as you need to be able to
record in realtime given an expected framerate. For example if your
*recorded* movies are twice as fast, try setting your *playback*
speed to half as fast, or even better, one quarter as fast to be sure
you can write *every* frame to disk as it is sent through your jitter
patch without dropping any frames.
2. use @unique 1 from your movie output to prevent redundant frames.
3. operate your patcher with the desired changes at a corresponding
speed to match the slow playback speed of your video.
This should let you work with any sized movies and any expensive
patch. You simply need to slow down the playback speed as much as you
need to match the desired output frame rate.
Hope this helps.
-Joshua
Joshua,
I too am having the non-realtime record patch producing incorrect timings.
I've used non-realtime recording for a few years now and it works quite well in the past.
But then all of a sudden, it doesn't work any longer. I'm not exactly sure what has changed in my setup, but what i do know is that that patch hasn't changed. I'm using the exact same patch and it records the video double or more. Even stranger it records it several times over.
For example, if I simply open the Jit Tutorial 19, and do the demo as described. My resulting video is correctly 10s long (the same as the original countdown video), but it has recorded the countdown 3 times at triple the speed (metro is off, etc)
I've attached the resulting video and below is the patch as text.
The only thing i have changed in this patch is the reduced jit.qt.rec dimensions (halved) so that i can attach the smaller resulting quicktime file. The timing glitch occurs in the original Tutorial patch and this one.
I am running MAX/MSP 4.6.1
Jitter 1.6.1
Quicktime 7.5.1
MAC OSX 10.4.9
Powerbook G4 1.5mHz
As a side note, i do have MAX/MSP 4.5.1 as a folder in my applications folder, does this have anything to do with my problem? Do i need to trash this older folder?
Thanks,
charles
On May 29, 2007, at 5:03 PM, charles stankievech wrote:
> I too am having the non-realtime record patch producing incorrect
> timings.
>
> I've used non-realtime recording for a few years now and it works
> quite well in the past.
>
> But then all of a sudden, it doesn't work any longer. I'm not
> exactly sure what has changed in my setup, but what i do know is
> that that patch hasn't changed. I'm using the exact same patch and
> it records the video double or more. Even stranger it records it
> several times over.
>
> I am running MAX/MSP 4.6.1
> Jitter 1.6.1
> Quicktime 7.5.1
Please update your Jitter version (and Max too), and let us know if
your problem persists.
-Joshua
Mr. Kit,
Simply updating from Jitter 1.6.1 to 1.6.3 seems to have solved the problem.
Sorry, should have tried this first, didn't know there was a newer version
Thanks greatly,
charles