[Bf-committers] Screen-cast issues

Andrew Green 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


100ms
Appended frame 1
-18ms
Appended frame 2
-117ms
Appended frame 3
-216ms
Appended frame 4
-327ms
Appended frame 5
-433ms
Appended frame 6
-537ms
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.
>>
>> /Nathan
>>
>>>
>>> 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.
>>>
>>> diffTime=currentTime-startTime;
>>> if(diffTime>=framePause){
>>>      saveCurrentFrame();
>>>      startTime+=framePause;
>>> }
>>>
>>> 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
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>>
>> - --
>> Nathan Letwory
>> Letwory Interactive
>> http://www.letworyinteractive.com
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.10 (MingW32)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iQEcBAEBAgAGBQJMoa40AAoJEKtfN7KsE0TtJvUH/0x7OFbtwD5axlBVQ+uCBduX
>> e5tj+urYKHeCFhF2N4c9MKS11H3Y5E3wjmh1TPWu+PTtd24BS7yYzxKhMya57G0Z
>> DlzTy+UAAt/MTnjj4EM6pN75PnJTgHeZnDh9ZzLG03Yg0KoC51B1KXGJeHDWA1c5
>> I3ge7d10YJySaNcU2qMqlP1n8HDbm39J1XCTCHIJaCh4KqymdmLOs//phnEydSzT
>> HCGiqQbINwvwYvtWYSgtWX/aMRjTUoJ1R5i1oasIBsGFtxuvrV2xR9uR2UEi98bU
>> n3YVzHpFL1/6OR/VbzWqCs5hDzCIZSDO8nr20vfIXZsfrZZ1eORgx+jvw2yDjkQ=
>> =0CS3
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>


More information about the Bf-committers mailing list