seejayjames

I'm capturing some desktop imagery from Xaos (which is really freakin cool and I'd love to interface it with MMJitter, by the way)

http://wmi.math.u-szeged.hu/xaos/doku.php

The capture is fine and even though the preview is laggy / chunky, plenty of frames are captured in the recording. What's confusing me is the playback -- the captured movie plays back quite a bit faster than expected. Seems like there's three things at work here:

1. The rate of capture into jit.desktop (I have it at fastest possible metro)

2. The rate of the recording (I tried 10-60 fps, 300-1200 timescale). they are all fast, and the lower frame rates simply miss more of the motion / frames.

3. The rate of the playback -- I tried a range of rates, but if you slow it down, you seem to miss a lot of frames, or maybe I'm being deceived.

I know this is probably RTFM but if anyone has run into this I'd love to hear about it. Some combination of the fps and the timecode in the recording is probably the answer. Also perhaps using duration to scale the finished movie? This seems to help but I can't quite tell if frames get dropped or not. I thought that recording at a high frame rate, then playing back slower, would approximate a smooth recording at a lower frame rate. Maybe that's exactly what it's doing but it still seems more choppy that I would have expected.

I know this is probably RTFM but if anyone has run into this I'd love to hear about it. Some combination of the fps and the timecode in the recording is probably the answer. Also perhaps  using duration to scale the finished movie? This seems to help but I can't quite tell if frames get dropped or not. I thought that recording at a high frame rate, then playing back slower, would approximate a smooth recording at a lower frame rate. Maybe that's exactly what it's doing but it still seems more choppy that I would have expected.

playback-rate-after-using-jit-desktop

The first RTFM-y thing that comes to mind when people talk about

their recordings being different lengths would be to ask if you'd

read about the realtime message to jit.qt.record. Have you?

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

The first RTFM-y thing that comes to mind when people talk about
their recordings being different lengths would be to ask if you'd
read about the realtime message to jit.qt.record. Have you?
-- 
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


http://wmi.math.u-szeged.hu/xaos/doku.php?id=documentation:manual:mpeg

> I'm capturing some desktop imagery from Xaos (which is really freakin cool

> and I'd love to interface it with MMJitter, by the way)

> The capture is fine and even though the preview is laggy / chunky, plenty

> of frames are captured in the recording. What's confusing me is the playback

> -- the captured movie plays back quite a bit faster than expected. Seems

> like there's three things at work here:

> 1. The rate of capture into jit.desktop (I have it at fastest possible

> 2. The rate of the recording (I tried 10-60 fps, 300-1200 timescale). they

> are all fast, and the lower frame rates simply miss more of the motion /

> 3. The rate of the playback -- I tried a range of rates, but if you slow

> it down, you seem to miss a lot of frames, or maybe I'm being deceived.

> I know this is probably RTFM but if anyone has run into this I'd love to

> hear about it. Some combination of the fps and the timecode in the recording

> is probably the answer. Also perhaps using duration to scale the finished

> movie? This seems to help but I can't quite tell if frames get dropped or

> not. I thought that recording at a high frame rate, then playing back

> slower, would approximate a smooth recording at a lower frame rate. Maybe

> that's exactly what it's doing but it still seems more choppy that I would

Have you tried
http://wmi.math.u-szeged.hu/xaos/doku.php?id=documentation:manual:mpeg
??

On 4/6/07, Seejay James  wrote:
>
>
> Hello,
>
> I'm capturing some desktop imagery from Xaos (which is really freakin cool
> and I'd love to interface it with MMJitter, by the way)
>
> http://wmi.math.u-szeged.hu/xaos/doku.php
>
> The capture is fine and even though the preview is laggy / chunky, plenty
> of frames are captured in the recording. What's confusing me is the playback
> -- the captured movie plays back quite a bit faster than expected. Seems
> like there's three things at work here:
>
> 1. The rate of capture into jit.desktop (I have it at fastest possible
> metro)
>
> 2. The rate of the recording (I tried 10-60 fps, 300-1200 timescale). they
> are all fast, and the lower frame rates simply miss more of the motion /
> frames.
>
> 3. The rate of the playback -- I tried a range of rates, but if you slow
> it down, you seem to miss a lot of frames, or maybe I'm being deceived.
>
> I know this is probably RTFM but if anyone has run into this I'd love to
> hear about it. Some combination of the fps and the timecode in the recording
> is probably the answer. Also perhaps  using duration to scale the finished
> movie? This seems to help but I can't quite tell if frames get dropped or
> not. I thought that recording at a high frame rate, then playing back
> slower, would approximate a smooth recording at a lower frame rate. Maybe
> that's exactly what it's doing but it still seems more choppy that I would
> have expected.
>
> Any input would be great, thanks,
>
> CJ
>

yes, the realtime definitely helped. and there it is, right in the help patch...

The playback is still stuttery (a bit), but now I know it's because of my aging computer rather than the commands I'm sending Jitter ;-)

The playback is still stuttery (a bit), but now I know it's because of my aging computer rather than the commands I'm sending Jitter   ;-)

I wanted to avoid using the rendering in Xaos itself as this takes a lot of time and effort. The screen capture works OK, good enough for my purposes... however, using the rendering does provide a smoother animation with higher quality frames, so that's something to consider in the future.

Playback rate after using jit.desktop