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 <greenie...@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 > <nat...@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@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@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers