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 zmoelnig@iem.at 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
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list