[Bf-committers] Screen-cast issues

[Andrew Green]

I have it worked out now. it seems to be working great. I'm not sure
who i should speak to about this patch. I would like to get read of
the managers use in the screen-cast, but it seems like it is only ever
in the right opengl context when that is used.



On Fri, Oct 1, 2010 at 12:49 AM, Andrew Green <greeniekin at gmail.com> wrote:
> 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
>>>
>>
>