On 2/17/07, <b class="gmail_sendername">Roman Haefeli</b> <<a href="mailto:reduzierer@yahoo.de">reduzierer@yahoo.de</a>> wrote:<div><span class="gmail_quote"></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>hm. i can see why someone would rather pd/gem have to drop one or the<br>another frame, if cpu-load is too high, when playing a movie-file,<br>instead of playing each frame in order, while losing timing. but why<br>would someone want [pix_record] to drop frames, while recording?
</blockquote><div><br>The answer is to keep in sync with time in the real world. An example would be if I make a ten second recording but the CPU is only able to grab and compress 240 frames. On playback setting each frame to a 33 ms duration would result in a movie eight seconds long which would playback faster than the events happened in real time. Setting average frame duration to around 42ms will play the 240 frames back over ten seconds. The resulting playback might have gaps but it will show the action in the same amount of time it originally occured.
<br><br></div><br><br></div><br>