[Bf-committers] Screen-cast issues
greeniekin at gmail.com
Thu Sep 30 16:49:05 CEST 2010
I have written some code to work out how long until the next frame is added.
My settings are fps:10 and wait-time:100ms
The number should say how many ms until the next frame is added.
The output is below
Appended frame 1
Appended frame 2
Appended frame 3
Appended frame 4
Appended frame 5
Appended frame 6
Appended frame 7
And so on.
Which is rather annoying as I was just going to replace the sleep time
with that number. so it would sleep shorter times when needed. Though
obviously a negative number won't work. I'm pretty sure there is an
error here. I will fiddle and see if I can get a solution. Any ideas
or comments would be much appreciated.
On Tue, Sep 28, 2010 at 9:37 PM, Andrew Green <greeniekin at gmail.com> wrote:
> I thought the fps in the render panel is not used for screen cast.
> In the user preference window it has 2 properties for screencast.
> FPS. which is described as the frame rate that the screencast is to be
> played back.
> Wait Timer(ms). which is described as the time in milliseconds between
> each frame recorded by screen cast.
> I played with changing the fps in the scene render panel and it didn't
> seem to do anything.
> On Tue, Sep 28, 2010 at 6:58 PM, Nathan Letwory
> <nathan at letworyinteractive.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> On 28.9.2010 8:42, Andrew Green wrote:
>>> I have been playing with the blender screen-cast functionality. I have
>>> noticed the timing never seems right for me.
>>> Even when I modify the settings for screen-cast to represent what
>>> should be a real time recording.
>>> It is off by a lot. if i record for 30 seconds i will get 15 or 20
>>> seconds video from it.
>> That's because in user preferences FPS for screen casting is by default
>> on 10. If you screencast directly to a movie, make sure you have the
>> same FPS.
>>> I think it's due to a couple of things.
>>> After it has written one frame it will simply sleep for x ms and then
>>> write the next frame. I'm pretty sure when it sleeps it will
>>> overshoot. Also there is the extra time to actually save the frame.
>>> This makes it worse over time.
>>> There is also the possibility that an image has not been grabbed
>>> yet(which is done separately by the job manager) when the loop resumes
>>> which means it will go and sleep for an extra x ms.
>>> I really haven't given it much thought. Would it be the best idea to
>>> get the system time when recording is started. Then use this to
>>> determine when a frame should be written. This way a frame may be
>>> saved slightly off time. Though the results wouldn't accumulate and
>>> throw the results completely off.
>>> Heres what i was thinking in a tiny bit more detail. It's simple plus
>>> if there is a system pause for 1 second when many frames should have
>>> been written it will write those frames and make sure the time match
>>> of the video and the real world.
>>> Would you guys agree that this is the cause of the issue?
>>> Do you guys feel this is sensible solution for me to implement? Or do
>>> you think I am crazy?
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>> - --
>> Nathan Letwory
>> Letwory Interactive
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.10 (MingW32)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>> -----END PGP SIGNATURE-----
>> Bf-committers mailing list
>> Bf-committers at blender.org
More information about the Bf-committers