double speed of the recordings


    May 19 2007 | 4:04 pm
    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

    • May 19 2007 | 4:15 pm
      >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
    • May 19 2007 | 4:24 pm
      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 >
    • May 19 2007 | 6:45 pm
      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
    • May 19 2007 | 8:43 pm
      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 >
    • May 19 2007 | 8:53 pm
      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
    • May 19 2007 | 9:22 pm
      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
    • May 30 2007 | 12:03 am
      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
    • May 30 2007 | 1:49 am
      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
    • May 30 2007 | 10:43 pm
      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