> switching off the [gemhead] will not push new frames into your [pix_record], > but it will not halt a "local time" (this is never what [gemhead] does).
Ah, I see now! Although this is expected behaviour, I still think it'd be useful to be able to pause recording (at least in this scenario) > - either manually force the framerate to a constant value when writing the > file (it might well be (haven't checked yet) that you actually cannot force > the framerate to a given value, which indeed could be considered a bug) I've checked the help file and options and of pix_record and there doesn't appear to be any options to set the frame rate. Please correct me if I'm wrong! I did a bit of further investigating and it appears that the framerate for the videos created by my patch/pix_record are craziliy high! Here's the sample video that I used http://dl.dropbox.com/u/350846/test.mov I ran the following command to get some information from the file mplayer -vo null -ao null -frames 0 -identify test.mov The important part of that information is that the fps is 1000000.000. Something isn't right there... On 28 December 2012 17:34, IOhannes m zmölnig <[email protected]> wrote: > On 12/28/2012 02:18, Antonio Roberts wrote: >>> >>> i cannot check your example right now, but this can totally be desired >>> behaviour. e.g. if your container supports variable framerates and you >>> record two frames that are 20 seconds appart, you might end up with a >>> 20sec >>> video containing of 2 frames. >>> (afair, you might be able to override the framerate (depending on the >>> backend/container you are using). >> >> >> This 20 seconds between frames is what I'm ending up with and I >> believe that it is a bug. > > > hmm, with "this" is assume you mean that you really get a frame duration of > 20 seconds (that is, your framerate is 0.05). > if so, then the behaviour is definitely not a bug, as you record two frames > and that are 20 seconds apart and you also get that. > switching off the [gemhead] will not push new frames into your [pix_record], > but it will not halt a "local time" (this is never what [gemhead] does). > > i understand that this behaviour is not what you want, but the way to fix it > is: > - either manually force the framerate to a constant value when writing the > file (it might well be (haven't checked yet) that you actually cannot force > the framerate to a given value, which indeed could be considered a bug) > - or ignore the framerate when playing back the file > - or fix the framerate once the file is written (but before you want to play > it back). > > >> As far as I understand, pix objects need a >> [gemhead] in order to function. If it is not present or is turned off >> then it shouldn't operate. What I'm finding is that once recording is >> turned on and then afterwards the gemhead is turned off, when it is >> turned back on and a frame captured the time between the two bangs is >> still recorded. > > > > for the sake of completeness: > there's a small chance of a problem with data caching. > [pix_record] will not write new frames if it doesn't receive a > render-trigger (usually originating from [gemhead]). > but once you turn it on again it might write pixel data that originates from > before turning on the [gemhead]. > > fadmsr > > IOhannes > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list -- ============================ [email protected] http://www.hellocatfood.com ============================ _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
