[PD] pix_record continues to record, even with rendering turned off

[Antonio Roberts]

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



-- 
============================
antonio at hellocatfood.com
http://www.hellocatfood.com
============================