Re: revVideoGrabber: stop preview doesn't hide video window

[Martin Koob]

> 
> I have dealt with the problem of stop preview window by using 
> closevideograbber to get rid of the preview window. 
> 

Huh? Doesn't that stop the capture? 

Sorry I was not clear.   

I have the revgrabber window in a substack.  This way I can hide the preview
of the recording by hiding and showing the substack.  This does not affect
the capture.

If I am not capturing, just previewing and I want to stop the preview I
close revvideograbber window and close the substack.

>yes, just changing the audio setting results in quirky behavior on the
video 
>side. I found the audio levels too *low* for monitoring. I was using VG for 
>archiving 8mm videos.  I went back to final cut. 

>Save the audio settings? -  how does one do that ? 
> It appears impossible because there's no commands documented for that.  If 
>one tries to save on top of the video settings... they get trounced.

I can save the audio settings with the revvideograbsettings command but like
you said the video settings that have been set are changed as well so I had
to take the audio settings feature out.

-- 
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/revVideoGrabber-stop-preview-doesn-t-hide-video-window-tp2315648p2317836.html
Sent from the Revolution - User mailing list archive at Nabble.com.
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: revVideoGrabber: stop preview doesn't hide video window

[stephen barncard]

On 8 August 2010 06:59, Martin Koob  wrote:

>
>
> I have dealt with the problem of stop preview window by using
> closevideograbber to get rid of the preview window.
>

Huh? Doesn't that stop the capture?




>
> The other annoyance is the inability to turn off the audio while
> previewing.
> Sometimesthat results in audio feedback depending on the placement
> of microphones and the volume setting of the Mac.
> You can use an undocumented keyword for revvideograbdialog
>
> revVideograbdialog "audio"
>
>  to see a QT audio dialog to turn off the
> sound while previewing but if you try to save the settings it results in
> problems with the video settings.
>
>
yes, just changing the audio setting results in quirky behavior on the video
side. I found the audio levels too *low* for monitoring. I was using VG for
archiving 8mm videos.  I went back to final cut.

Save the audio settings? -  how does one do that ?
 It appears impossible because there's no commands documented for that.  If
one tries to save on top of the video settings... they get trounced.


Stephen Barncard
San Francisco Ca. USA

more about sqb  
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: revVideoGrabber: stop preview doesn't hide video window

[Martin Koob]

Ben Rubinstein  writes:

> 
> Thanks, Stephen and Richard.
> 
> Because I'm selfishly focused on my immediate needs, can you clarify "long 
> grabs" and "problems"?  Are long grabs like Stephen's two hours, or would 
> five 
> minutes qualify?  Are problems sync drift, or crashing, or memory leaks, 
> or... 
> something else?
> 
> My application will probably not be doing more than a few minutes per clip - 
> but it will be doing lots and lots of them over a day. Obviously I'll be 
> testing this for myself - but it would be good to have tips on what to look 
> out for.
> 
> Many thanks,
> 
> Ben
> 

I have a mac application that uses revVideograbber extensively and
the captures range from a few minutes to over an hour.   I have not noticed
sync issues.

I have dealt with the problem of stop preview window by using 
closevideograbber to get rid of the preview window.

One of the things I have noticed is the high CPU use while previewing or 
recording. It is higher than other mac applications that capture video.

The other annoyance is the inability to turn off the audio while previewing.  
Sometimesthat results in audio feedback depending on the placement 
of microphones and the volume setting of the Mac.  
You can use an undocumented keyword for revvideograbdialog 

revVideograbdialog "audio" 

 to see a QT audio dialog to turn off the 
sound while previewing but if you try to save the settings it results in
problems with the video settings.



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: revVideoGrabber: stop preview doesn't hide video window

[Richard Miller]

Ben,

We limit grabs to 3 minutes now, but I suspect we could go longer. It 
really depends on the processor and camera involved (and probably the 
audio input source as well)... tremendous variability. Only testing will 
tell.


We sell a customized "kiosk" driven entirely by Rev. This kiosk now uses 
a dual-core Pentium and a machine-vision camera capturing at 60 frames 
per second, all under Windows 7. We had problems when using a slower 
Atom processor, but the new processor allows the videograb functions to 
work much more smoothly. For example, even during video capture, the 
live Preview screen still shows fluid motion. Before, it would be jerky 
and only show perhaps 1/4 of the actual frames.


We're not seeing any syncing issues with the audio using this 
configuration. No crashing. No problems.


Richard


On 8/8/10 5:05 AM, Ben Rubinstein wrote:

Thanks, Stephen and Richard.

Because I'm selfishly focused on my immediate needs, can you clarify 
"long grabs" and "problems"?  Are long grabs like Stephen's two hours, 
or would five minutes qualify?  Are problems sync drift, or crashing, 
or memory leaks, or... something else?


My application will probably not be doing more than a few minutes per 
clip - but it will be doing lots and lots of them over a day. 
Obviously I'll be testing this for myself - but it would be good to 
have tips on what to look out for.


Many thanks,

Ben


On 08/08/2010 01:54, Richard Miller wrote:

Yes. Long grabs are where we've encountered problems.

Richard Miller



On 8/7/10 11:35 AM, Ben Rubinstein wrote:

Is it long grabs (my next set of tests) that is the problem?

Many thanks,

Ben

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: revVideoGrabber: stop preview doesn't hide video window

[Ben Rubinstein]

Thanks, Stephen and Richard.

Because I'm selfishly focused on my immediate needs, can you clarify "long 
grabs" and "problems"?  Are long grabs like Stephen's two hours, or would five 
minutes qualify?  Are problems sync drift, or crashing, or memory leaks, or... 
something else?


My application will probably not be doing more than a few minutes per clip - 
but it will be doing lots and lots of them over a day. Obviously I'll be 
testing this for myself - but it would be good to have tips on what to look 
out for.


Many thanks,

Ben


On 08/08/2010 01:54, Richard Miller wrote:

Yes. Long grabs are where we've encountered problems.

Richard Miller



On 8/7/10 11:35 AM, Ben Rubinstein wrote:

Is it long grabs (my next set of tests) that is the problem?

Many thanks,

Ben

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: revVideoGrabber: stop preview doesn't hide video window

[Richard Miller]

Yes. Long grabs are where we've encountered problems.

Richard Miller



On 8/7/10 11:35 AM, Ben Rubinstein wrote:

Is it long grabs (my next set of tests) that is the problem?

Many thanks,

Ben 


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: revVideoGrabber: stop preview doesn't hide video window

[stephen barncard]

It depends of what you define as 'long'.  I was transferring entire 8mm
tapes at SD DV resolution - 2 hrs - and generating up to 24g files.  I would
get sync issues as big as 10 seconds sometimes. Other times not.

Videograbber could be extremely useful for archiving. Video transfer and
database integrated into one app. An archivist's dream.

The audio issues are puzzling, and indicate an external sort of half-baked.
I suspect that these issues are related to the ambiguity of the audio for
videograbber, especially when the audio panel is used, which seems to make
things worse.

Doesn't anybody test these things before release?

On 7 August 2010 08:35, Ben Rubinstein  wrote:

> Thanks for the confirmation Richard, I've added a report to RQCC for this
> issue.
>
> I'm a bit perturbed by the combination of the "The PC side works much
> better than the Mac side" with "runs with adequate stability even for video
> grabs as long as 3-5 minutes".  The latter seems to me to be a doubly low
> standard: "adequate stability" and "as long as...".
>
> So far my testing (on Mac) with a rig cycling round initialising, setting
> settings, preview, capture (for short capture runs at this point, ie 5
> seconds) and closing the video grabber has captured approx 2,000 clips over
> a nine hour period without evident issues.  Should I infer from your remarks
> that I got lucky?  Is it long grabs (my next set of tests) that is the
> problem?
>
> Many thanks,
>
> Ben
>
>
> On 06/08/2010 00:38, Richard Miller wrote:
>
>> Ben,
>>
>> We use the video grabber functions extensively in our software, but only
>> on PC's (where it runs with adequate stability even for video grabs as
>> long as 3-5 minutes). The PC side works much better than the Mac side.
>>
>> The issue you are running into on a Mac is a known bug. You're not doing
>> anything wrong. But I've not found it a problem to use
>> revCloseVIdeoGrabber as often as needed (on Mac or PC side)... because
>> you are right in saying it is the only way to get rid of the preview
>> image on a Mac.
>>
>> Richard Miller
>>
>>
>> On 8/5/10 5:39 PM, Ben Rubinstein wrote:
>>
>>> Docs for revStopPreviewingVideo says:
>>> "Stops showing input from a video camera in the video grabber window."
>>> "Use the revStopPreviewingVideo command to stop showing video input."
>>> "When you stop previewing video, the video grabber window shows a
>>> blank screen."
>>>
>>> When I try this (rev 4.0 or later, on MacOS X 10.6) it doesn't show a
>>> blank screen, instead I'm left with a still of the last frame. The
>>> only way to make it go away is to execute revCloseVideoGrabber.
>>>
>>> Is this a known bug? Am I doing something wrong? Does anyone else
>>> experience this, or conversely has anyone experience of it working as
>>> documented?
>>>
>>> TIA,
>>>
>>> Ben
>>>
>> ___
> use-revolution mailing list
> use-revolution@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>



-- 



Stephen Barncard
San Francisco Ca. USA

more about sqb  
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: revVideoGrabber: stop preview doesn't hide video window

[Ben Rubinstein]

Thanks for the confirmation Richard, I've added a report to RQCC for this issue.

I'm a bit perturbed by the combination of the "The PC side works much better 
than the Mac side" with "runs with adequate stability even for video grabs as 
long as 3-5 minutes".  The latter seems to me to be a doubly low standard: 
"adequate stability" and "as long as...".


So far my testing (on Mac) with a rig cycling round initialising, setting 
settings, preview, capture (for short capture runs at this point, ie 5 
seconds) and closing the video grabber has captured approx 2,000 clips over a 
nine hour period without evident issues.  Should I infer from your remarks 
that I got lucky?  Is it long grabs (my next set of tests) that is the problem?


Many thanks,

Ben

On 06/08/2010 00:38, Richard Miller wrote:

Ben,

We use the video grabber functions extensively in our software, but only
on PC's (where it runs with adequate stability even for video grabs as
long as 3-5 minutes). The PC side works much better than the Mac side.

The issue you are running into on a Mac is a known bug. You're not doing
anything wrong. But I've not found it a problem to use
revCloseVIdeoGrabber as often as needed (on Mac or PC side)... because
you are right in saying it is the only way to get rid of the preview
image on a Mac.

Richard Miller


On 8/5/10 5:39 PM, Ben Rubinstein wrote:

Docs for revStopPreviewingVideo says:
"Stops showing input from a video camera in the video grabber window."
"Use the revStopPreviewingVideo command to stop showing video input."
"When you stop previewing video, the video grabber window shows a
blank screen."

When I try this (rev 4.0 or later, on MacOS X 10.6) it doesn't show a
blank screen, instead I'm left with a still of the last frame. The
only way to make it go away is to execute revCloseVideoGrabber.

Is this a known bug? Am I doing something wrong? Does anyone else
experience this, or conversely has anyone experience of it working as
documented?

TIA,

Ben

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: revVideoGrabber: stop preview doesn't hide video window

[Richard Miller]

Ben,

We use the video grabber functions extensively in our software, but only 
on PC's (where it runs with adequate stability even for video grabs as 
long as 3-5 minutes). The PC side works much better than the Mac side.


The issue you are running into on a Mac is a known bug. You're not doing 
anything wrong. But I've not found it a problem to use 
revCloseVIdeoGrabber as often as needed (on Mac or PC side)... because 
you are right in saying it is the only way to get rid of the preview 
image on a Mac.


Richard Miller


On 8/5/10 5:39 PM, Ben Rubinstein wrote:

Docs for revStopPreviewingVideo says:
"Stops showing input from a video camera in the video grabber window."
"Use the revStopPreviewingVideo command to stop showing video input."
"When you stop previewing video, the video grabber window shows a 
blank screen."


When I try this (rev 4.0 or later, on MacOS X 10.6) it doesn't show a 
blank screen, instead I'm left with a still of the last frame.  The 
only way to make it go away is to execute revCloseVideoGrabber.


Is this a known bug?  Am I doing something wrong?  Does anyone else 
experience this, or conversely has anyone experience of it working as 
documented?


TIA,

Ben
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

revVideoGrabber: stop preview doesn't hide video window

[Ben Rubinstein]

Docs for revStopPreviewingVideo says:
"Stops showing input from a video camera in the video grabber window."
"Use the revStopPreviewingVideo command to stop showing video input."
"When you stop previewing video, the video grabber window shows a blank screen."

When I try this (rev 4.0 or later, on MacOS X 10.6) it doesn't show a blank 
screen, instead I'm left with a still of the last frame.  The only way to make 
it go away is to execute revCloseVideoGrabber.


Is this a known bug?  Am I doing something wrong?  Does anyone else experience 
this, or conversely has anyone experience of it working as documented?


TIA,

Ben
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution