Reducing flash with revVideoGrabber - any suggestions?

David Bovill david at vaudevillecourt.tv
Mon Sep 13 08:08:32 EDT 2010


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_mc at 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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>



More information about the use-livecode mailing list