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