revVideoGrabber: stop preview doesn't hide video window

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

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

Richard Miller-5
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
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

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

Stephen Barncard-4
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 <[hidden email]> 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
> [hidden email]
> 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  <http://www.google.com/profiles/sbarncar>
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

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

Richard Miller-5
In reply to this post by Ben Rubinstein
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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

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

Richard Miller-5
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
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

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

Martin Koob
In reply to this post by Ben Rubinstein
Ben Rubinstein <benr_mc@...> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

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

Stephen Barncard-4
On 8 August 2010 06:59, Martin Koob <[hidden email]> 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  <http://www.google.com/profiles/sbarncar>
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

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.