[PD] pix_record -> pix_film plays back too fast

[chris clepper]

pix_record uses the actual time passed between frames when writing a
Quicktime file.  This is proven accurate in my testing (probably a million
files at this point).  One thing you will not get is a perfect 29.97 file
though.  That requires either offline processing like Final Cut or a
dedicated clock like a DV cam.

The more objects running the longer the time between frames, plus the time
it takes to compress the frame means that it can take a while to record.
The choice of codec is very important too.  H.264 is not going to work well
for real time capture, but Apple Intermediate is designed for it.

On Mon, Aug 4, 2008 at 3:14 PM, Spencer Russell <spencer.f.russell at gmail.com
> wrote:

> I'm using pix_record to write processed video captured live from a DV
> cam to disk, and then playing it back with pix_film. Unfortunately, it
> seems to record at around 16fps even though GEM should be running at
> 20. I tried lowering GEM to 15 fps thinking that maybe it was having
> trouble keeping up, but then it wrote at around 12fps. The framerates
> are the ones that show up in Quicktime player, and seems to be the
> same as when I play back with pix_film. I've tried recording both with
> [auto 1( and banging it with a metro, but strangely it doesn't seem to
> matter how fast I run the metro. I tried it at 15 fps and 50fps with
> the gemwin at 20fps and the recorded video seemed to be the same.
>
> What controls the framerate of pix_record and pix_film? I'd think that
> using [auto 1( would do both of them at the GEM rate, but apparently
> that seems to not be happening.
>
> This is on my friend's MacBook pro running OS X.
>
> thanks in advance,
> spencer
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20080804/e791db5b/attachment.htm>