Re: [Bf-committers] Screen-cast issues
On 30/10/10 10:58 AM, Mike S wrote: > On 30/10/10 10:37 AM, Andrew Green wrote: >> In user preferences it has screen cast fps and frame speed. I thought >> screencast fps was the fps of the video format. And the frame speed was how >> many ms between adding a frame to the video. >> >> So I do not understand what the difference is between the 2 different fps >> settings. > > Screencast only captures static images (png from memory) to your /tmp > (unix/mac) or whatever your defualt dir is. It is up to you to then use > the VSE to create a movie format from those static images. This is done > to minimise CPU time spent encoding video when you want nice UI performance. Oops...I see now that the output from screencast is not fixed png but selectable by the render output type (never tried before:)!) . The screen capture rate is still determined by the capture settings in User Pref. Possibly why they are seperate is to allow you to screen cast at lower rates and at the same time demonstrate setting up VSE or render settings to another value? All the action is here::: source/blender/editors/screen/screendump.c The problem mentioned below still occurs regardless of capture type. Trying to find out why. > However at the moment there are a few bugs in screeencast. One > particular is that if you change anything in the Last Operator panel on > the toolbar ( "T" and at the bottom of that is the last operator) it > will cancel your screencast. > > Cheers, > > Mike. > > ___ > 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
Re: [Bf-committers] Screen-cast issues
On 30/10/10 10:37 AM, Andrew Green wrote: > In user preferences it has screen cast fps and frame speed. I thought > screencast fps was the fps of the video format. And the frame speed was how > many ms between adding a frame to the video. > > So I do not understand what the difference is between the 2 different fps > settings. Screencast only captures static images (png from memory) to your /tmp (unix/mac) or whatever your defualt dir is. It is up to you to then use the VSE to create a movie format from those static images. This is done to minimise CPU time spent encoding video when you want nice UI performance. However at the moment there are a few bugs in screeencast. One particular is that if you change anything in the Last Operator panel on the toolbar ( "T" and at the bottom of that is the last operator) it will cancel your screencast. Cheers, Mike. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Screen-cast issues
In user preferences it has screen cast fps and frame speed. I thought screencast fps was the fps of the video format. And the frame speed was how many ms between adding a frame to the video. So I do not understand what the difference is between the 2 different fps settings. On 28/09/2010 6:58 PM, "Nathan Letwory" 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 functiona... 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 ... > ___ > 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
Re: [Bf-committers] Screen-cast issues
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 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 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
>> 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
Re: [Bf-committers] Screen-cast issues
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 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
> 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
Re: [Bf-committers] Screen-cast issues
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
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
Re: [Bf-committers] Screen-cast issues
-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] Screen-cast issues
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.
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
