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
