[Prev][Next][Index][Thread]

Movies and auto-brightness

On Wed, 31 Jan 1996, Roger A. Unwin wrote:

> In an E-mail message, Paul Chinn wrote:
> > 
> > Ok guys, let's solve this one.  Windows can record decently to disk and
> > they are even going thru VideoForWindows layer, so *we* should be able
> > rock.  Here's 3 methods I've explored and the main problems with each.
> > 
> > * asynchronous file i/o- when data is flushed several frames get lost.
> > Framerate at any give moment is very good, but lost frames cause a bad
> > reduction in overall framerate- plus jarring gaps in motion.
> > 
> > * file i/o with syncs- leads to constant framerate- but at a seriously
> > degraded level.
> > 
> > * all in memory- some of my initial testing was encouraging but others,
> > especially with large frame sizes lead to a swap-o-rama. People's RAM &
> > swap space are certainly much smaller than available regular disk space.
> > 
> >  Another method I'm considering: opening a pipe and forking.  The
> > recording process writes to the pipe and the child manages bufferring
> > and writing.  My theory is that while the parent is sleep()ing the child
> > will get yielded time and write its data...
> 
> now, what if you anticipate the size needed to store the images.
> pre malloc it. then write to it, hopefuly forcing the swaping prior to
> the image capture.

Well, it would make sense to malloc() as much space as possible (Perhaps
a command line option to vary RAM cache size, with default of say, 2 megs.)

As I recall, a large realloc() would take too much time to finish. Perhaps
a FIFO cache that (as loomer suggested) dumps out to a forked process.

Possible problems with this (that I can see):
1) FIFO get overflowwed and frames are lost. If disk access is too slow,
   this will probably happen. So the first n frames will be fine, but it
   would degrade once the FIFO was full.
2) Disk access from forked process slows system response. Not damn likely
   on a fast IDE/SCSI system, but possible.
3) Swapping takes place from large malloc() call and swapping slows system
   down. Avoidable with a smaller FIFO, but that might result in lost frames.

Also, on a somewhat unrelated topic, would there be a way to have auto-
brightness implemented into the qcam drivers? I've just given the info
a cursory glance, and I know very little of graphics formats, but is it
possible to do a quick "brightness check" of an image? (ie: add up values of
pixels in certain areas, like a hot-spot in the middle plus a few other
points around, divide it by the # of pixels checked, and adjust brightness
until the average value is within a certain range.) I don't think it'd be
too tough to implement, as it's just greyscale. You smart guys out there
tell me, though. 8-)

Later,
-B

Brandon High    http://www.ccnet.com/~bjhigh    Down with Big Brother!
bjhigh@ccnet.com      bjhigh@ucdavis.edu      armitage@ece.ucdavis.edu
--
It is people like you that cause running sores to fester.
References: