Reducing flash with revVideoGrabber - any suggestions?

2010-09-13 Thread Ben Rubinstein
I'm working on a kiosk which will regularly record short clips of video.  At a 
certain point in the sequence I open the video grabber and start previewing 
the video; subsequently I start recording, then switch back to preview, then 
close the VG altogether.  Rinse, repeat.


Each time the VG is initialised, the VG rectangle goes white for approximately 
three quarters of a second.  Unfortunately in our design the screen is mostly 
very dark, so the white shows up really strongly.


I've tried various things to reduce this - eg tying the video grabber to a 
featureless borderless sub-stack the size of the video rectangle, and hiding 
it, putting it offscreen, or putting it behind the mainstack while it 
initialises.  Most of these fail altogether.


The best I've managed to do is with the substack hidden; initialise the VG, 
start previewing, and give it a full second before showing the substack (I've 
noticed when the video actually starts, it also sometimes (?) appears dark, 
and takes a few frames to come to a balance - presumably this is down to the 
camera). Doing it this way I still get a white flash, but it's extremely short.


Although the substack is hidden, the flash appears where the substack is.  So 
I can manipulate the position of the flash, by moving the hidden substack 
before I initialise the VG, and then moving the substack into the correct 
position immediately before making it visible, after the VG has had its second 
to 'warm up'.  If the hidden substack is moved entirely offscreen, then the 
whole thing fails; there's no flash, but when the substack is moved back into 
position and shown, there's no video either, just a white rectangle.  However, 
if the hidden substack is partially onscreen, partially off, then the white 
flash is limited to the 
area-that-would-be-visible-if-the-substack-wasn't-hidden, and when the 
substack moved to the correct position and shown, it all works correctly.


Hence the best I've managed to do is move the the substack so far off the 
bottom right of the screen that there's just one pixel it of it onscreen; the 
white flash is then reduced to a single pixel.  Unfortunately because the 
overall design of the kiosk is very dark, this is still visible - but a lot 
less intrusive than what we started with.  Although having to warm up the VG a 
second before I want to use it is a bore I can easily fairly easily accomodate 
this within the control flow.


So I do now have a reasonable workaround (confession: I hadn't got this far 
when I started writing this email).  But is this the best one can do?  Is 
there a better approach altogether that I've missed?


(The obviously completely different approach is to initialise the VG once when 
the kiosk launches, and leave it running all day, hiding and showing the 
preview/record stack as necessary.  However this is going to be in a 
high-traffic and high-profile location, from launch, and there's not long 
before launch; so I'm nervous about doing this without more time for soak 
testing, given various anecdotes I've heard about drifting sync etc.  But if 
there's contrary experience that this can work reliably, I'd be interested to 
hear about that also.)


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: Reducing flash with revVideoGrabber - any suggestions?

2010-09-13 Thread David Bovill
AFAIK - you've done the best that you can do with rev based hacks.

Maybe you could contact Kevin and ask for the source code? I think there are
a few other people that would really like this external improved and it
would make a great open source project - especially if you could put a small
ransom on it?

On 13 September 2010 12:32, Ben Rubinstein benr...@cogapp.com wrote:

 I'm working on a kiosk which will regularly record short clips of video.
  At a certain point in the sequence I open the video grabber and start
 previewing the video; subsequently I start recording, then switch back to
 preview, then close the VG altogether.  Rinse, repeat.

 Each time the VG is initialised, the VG rectangle goes white for
 approximately three quarters of a second.  Unfortunately in our design the
 screen is mostly very dark, so the white shows up really strongly.

 I've tried various things to reduce this - eg tying the video grabber to a
 featureless borderless sub-stack the size of the video rectangle, and hiding
 it, putting it offscreen, or putting it behind the mainstack while it
 initialises.  Most of these fail altogether.

 The best I've managed to do is with the substack hidden; initialise the VG,
 start previewing, and give it a full second before showing the substack
 (I've noticed when the video actually starts, it also sometimes (?) appears
 dark, and takes a few frames to come to a balance - presumably this is down
 to the camera). Doing it this way I still get a white flash, but it's
 extremely short.

 Although the substack is hidden, the flash appears where the substack is.
  So I can manipulate the position of the flash, by moving the hidden
 substack before I initialise the VG, and then moving the substack into the
 correct position immediately before making it visible, after the VG has had
 its second to 'warm up'.  If the hidden substack is moved entirely
 offscreen, then the whole thing fails; there's no flash, but when the
 substack is moved back into position and shown, there's no video either,
 just a white rectangle.  However, if the hidden substack is partially
 onscreen, partially off, then the white flash is limited to the
 area-that-would-be-visible-if-the-substack-wasn't-hidden, and when the
 substack moved to the correct position and shown, it all works correctly.

 Hence the best I've managed to do is move the the substack so far off the
 bottom right of the screen that there's just one pixel it of it onscreen;
 the white flash is then reduced to a single pixel.  Unfortunately because
 the overall design of the kiosk is very dark, this is still visible - but a
 lot less intrusive than what we started with.  Although having to warm up
 the VG a second before I want to use it is a bore I can easily fairly easily
 accomodate this within the control flow.

 So I do now have a reasonable workaround (confession: I hadn't got this far
 when I started writing this email).  But is this the best one can do?  Is
 there a better approach altogether that I've missed?

 (The obviously completely different approach is to initialise the VG once
 when the kiosk launches, and leave it running all day, hiding and showing
 the preview/record stack as necessary.  However this is going to be in a
 high-traffic and high-profile location, from launch, and there's not long
 before launch; so I'm nervous about doing this without more time for soak
 testing, given various anecdotes I've heard about drifting sync etc.  But if
 there's contrary experience that this can work reliably, I'd be interested
 to hear about that also.)

 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